Does anybody know if there are standard/preferred/conventional file name suffixes for jme-bin and jmexml files?
Even for the XML format, it is very useful to have a more specific suffix than "*.xml" so that we can immediately recognize jmexml files when we see them (just like for the XML files *.blend, *.xhtml, *.wxs,…). If *.xml is preferred, then I'd suggest a lax, informal convention of *-jme.xml, similar to the lax, informal convention of build.xml for Ant build files. The other important motivation for this is to support Subversion automatic properties both in the JME baseline and for application repositories.
My searches of docs, forums, and code bases are so far unsuccessful. Looks like the files bike.jme and camera.jbf in the 2.0 baseline may both be jme-bin format, but two conflicting conventions doesn't help me.
I'm going to PM hevee and dougnukem to alert them of the survey, since we have jmexml thanks to them.
UPDATE: dougnukem got back to me. He prefers suffix of ".xml" and to let the schema/DTD specify the semantics, but "If the majority of people using the XML format wants to see .jmexml, or .xjme, then you should definitely go ahead with that."
I just now noticed that the exporter for Blender automatically adds suffix ".xml", and is quite adamant about it. I suppose usage (so far) of the Blender exporter doesn't justify confirming to it, but if there is a maintainer issue with it (as is the case way too often with open source add-ons), or if there are other exporters or importers out there that default to ".xml", I think we should conform to that. Since we want the ability to visually and programmatically identify the files, I vote for *-jme.xml unless somebody assures me maintainers are ready (or willing helpers have privileges) to udpate tools accordingly.
I'm fine with .xml
Im kinda with blaine, they should have something that differentiates them from the blender export files easily…
So i guess my vote is *-jme.xml …
I'd prefer it to be something other than .xml, either .xjme or jme.xml is fine I guess, though I just like the look of .xjme a bit more.
I like *.xjme as an extension.
How about .jml?
daddison said:
How about .jml?
Heh, I like that. I'm changing my vote from *.xjme to *.jml :)
I was thinking .xjme, but .jml sounds better. I'll throw in .jmxl
since we're not using dos 8.3 anymore i vote for *.jmexml 
Im with CD here… .jmexml
Adopting this format also allows for a common theme for other extensions -
.jmeobj .jmebin .jmeanim etc etc all of which are easily readable at a single glance.
I don't like *-jme.xml as its mixing the name and the extension to form the extension, and I dont think a "." is allowed in a mime type (dont quote me on that!!) -not that thats what we are aiming for, but there may be a time when JME files are loadable by other applications, so sticking to a recognised standard is a good idea?
Also is a bit annoying for parsing the extension as it crosses the "." - hunting for last instanceof . and grabbing rest of string is much cleaner (trivial, but things like that annoy me :D)
JOC said:
...
I don't like *-jme.xml as its mixing the name and the extension to form the extension, and I dont think a "." is allowed in a mime type (dont quote me on that!!) -not that thats what we are aiming for, but there may be a time when JME files are loadable by other applications, so sticking to a recognised standard is a good idea?
The mime type concern is misplaced. The mime type should be text/xml (with semantic type determined by name space). This is an important advantage of leaving the final portion of the suffix *.xml.
The final ".xml" ending itself (with or without "jme" before) is a very "recognized standard", one of the most recognized and used file naming conventions in existence. There are dozens of XML editors and other XML apps (incl. IDEs that support XML) that will recognize the file as XML because of the final ending of *.xml. All that is needed to support the many XML apps is *.xml + a name space header internally (we will get to the latter requirement eventually).
Postnote: I just thought of a specific example to show the usefulness of the final *.xml portion. Firefox3 (without any plugins or add-ons) can be used as a good viewer for our XML files if they end with *.xml. It allows you to collapse/expand nodes like an XML editor/IDE. That would work for drilling down when viewing the code base or apps online, as well as for local files.
Also is a bit annoying for parsing the extension as it crosses the "." - hunting for last instanceof . and grabbing rest of string is much cleaner (trivial, but things like that annoy me :D)
What utility are you thinking of, which makes it easier to search for "*.xyz" than for "*-abc.xyz"? The suffix *-jme.xml allows for both more general searching for *.xml and more specific searching for *-jme.xml. I do tons of scripting plus my fair share of programmatic and graphical filename filtering and I never encounter the least difficulty searching for *build.xml (the convention that I use for Ant build files).
The whole strategy is not without precedent. Ant build files are usually named *build*.xml. Since, AFAIK, nobody has documented this, there is no consistency between sequence and delimiter for the "build" portion... it would be good if we could avoid inconsistency like that since it makes global searches and other actions much more difficult.
This form also allows for applications or sub-products to name modified variants of our XML format like *-jmemat.xml, *-kgamejme.xml, and to still enjoy the benefits of *.xml.
*.jme has in the past and should refer to the binary format. I think we should host a vote to decide on an extension for the xml format.
I suggest *.xjme
Sounds good.
Do you mean an informal pole, like people should post their opinions here, perhaps with an announcement to get more input; or is there some forum feature to poll/vote? Either way, could I get you to get it going, buddy?
blaine said:
Do you mean an informal pole, like people should post their opinions here, perhaps with an announcement to get more input; or is there some forum feature to poll/vote? Either way, could I get you to get it going, buddy?
Sure.
Everyone post here what you think the extension should be for the jME XML format.
Note: *.jme is already used for the binary format, so please don't suggest that one.
If we get a bunch of opinions then we'll start a poll to decide. If not, then I think the decision will be easy. :wink:
1. *.xml
2. *-jme.xml
3. *.xjme
4.
I think .xjme would be appropriate.
(my first thought was why not .jmex; but that is already a package in jME so would probably be confusing to some…)
All true fair points - but I'll try to defend myself (without pleading total insanity :|)
The mime concern wasn't really a concern, more me trying to quickly come up with an example to show that whatever was chosen might need to conform to some external ideals whilst keeping whatever was chosen as being immediately recognisable as something JME related.
You are absolutely correct, and superbly define that with your xml example - however not all jme related files would be xml. I thought of using mime types as an example here as they tend can map a type back to a file extension (as you said - text/xml > .xml). Now if .bin was chosen for binaries and required a suffix before the . to define the type of bin, you couldn't map a type to "jme.bin" (?? i think?? ). I guess I could have explained better (and still feel im struggling now) but obviously didn't think anywhere near long or hard enough and it was a bad example to choose - I do that a lot).
Following up on your postnote - if .xml was used as a file extension - then you wouldn't be able to register another application as the default handler for, say, JME xml - models if you directly wanted to load them into a viewer on a click (ok nothing exists for that yet in JME directly, but many people must be writing tools like this). For example - say someone wanted to write a blender importer for JME files ?
As for the parsing - yup I sounded like a dumbass there - yes its trivial from a code perspective (as I said) - but having a single method somewhere that does something like "get file extension" or rather "process file by extension" now has multiple definitions of what a file extension is (back to suffix/extension).
All really minor points, and highlight how bad I am at explaining myself, but there is a reason the first thing I do after installing windows is uncheck the "hide extension for known types" - that is where I look to know what kind of file something is and what I use to sort them 
Excellent point about setting OS "handlers" for file type extensions. I think this, mime-typing, and the file-manager ability to sort or filter by "extension" (defined by .) are the only cases where placement of the dot matters.
Since there can only be one . extension, we can't satisfy both XML-general and JME-specific app handlers. I am of the opinion that it is better to support the hundreds of apps that now work with *.xml extension, rather than break those to accommodate imagined future apps.
–
Getting a little off-topic, but I just thought of a rather useful elaboration of my Firefox-browsing idea. We could map a dump keyboard shortcut key to SimpleGame (or somewhere similar) to dump a snapshot of the current scene (or selected subgraph) to a temp file (as determined by the java.io routine). This would be a very useful-friendly way to interrogate a running app using your favorite XML editor or Firefox.
nymon or basixs:
I don't think some of the voters considered the implications beyond what looks good, but nevertheless, could you make a ruling on the XML format filename suffix? My vote is below, but if you are going with something that doesn't retain ".xml" at the end, I side with CD in thinking that a more descriptive suffix like .jmexml would be much more informative than .xjme and wouldn't add any new constraint (such as OS or network support).
I'll set subversion file properties, and the Blender exporter default accordingly. (I've taken over the jmexml project which houses the Blender exporter.)
A per the discussion here, I have been convinced that a straight *.xml extension is the smartest choice. I motion to use that.