
Dear all, Please find my 2 cents worth of comments regarding Andrew's Internet draft.
We have several reasons for not encouraging anything other than .xml as the file extension: 1) We have used .cml (which conflicted with other markup languages, like Chemical Markup Language) in the past, and changed to .xml. Having a history of too many file extensions makes it hard to encourage software vendors to stick with a particular one.
Just for accuracy, I believe to be the one who started using .cml in my software (http://cor.physiol.ox.ac.uk/). Are there others who do so too now? You mention that .cml conflicts with other markup languages, but I would argue that .xml conflicts with even more markup languages. Personally, .cml is not used on my system by anything else but for CellML files, so I don't have that conflict you mention, while it wouldn't be the case if my CellML files were to have the .xml extension. As for a history of file extensions, again, as far I can recall (please correct me if I am wrong), .xml has been the extension chosen for CellML files from day one. It's just me who has been some kind of a dissident for going for .cml from day one too (more on the reasons below).
2) There is currently repository software which uses .xml, and changing this will likely create problems for (some) client software using the repositories.
You will always have problems of some sort or another. To go from CellML 1.0 to 1.1 is not a trivial thing either, be it for the software developer or modeller. To change the file extension from .xml to whatever surely is a very trivial problem, at least of the kind that I would be glad to deal with on a daily basis, if they were to be the only problems I had to have!
3) Many users of CellML like to edit their models as XML in a text editor. Using the XML extension allows this to work on systems which know nothing about CellML.
Many CellML users like to edit their models as XML in a text editor? Is that really true? I certainly don't want to start an argument here, but I somehow think that my users would feel very strongly about having to modify CellML files using a simple text editor. I am, personally, very glad that I don't have to use a text editor, nothing worse than modifying a CellML file than using such an editor (very much error prone!). Allow me another quick plug in: have a look at COR and you might change your mind and never use a text editor in the future (though you might still want to do that once in a while for whatever reason). Also, it is very simple, on any operating system, to associate a particular extension to a particular problem.
4) Using a specific extension encourages software vendors to rely on this file extension. Although all software developed at the Bioengineering Institute does not rely on a specific file extension, there is software developed elsewhere that will not open files which do not have a .cml file extension (even when the user specifically tries to open that file in the program), and I have heard that this is creating problems for users.
I believe that it would have to be my software indeed... I have had several email exchanges with David Nickerson about this over the last few years. In a nutshell, the main reason I am rather reluctant about the idea of using .xml for CellML files is that by having using .cml, I can associate that extension to COR, while the same cannot really be done with .xml. My point is that COR has been designed from the beginning to be as user friendly as possible. It is something that is very high on our agenda and that has surely been very much appreciated by our users (from what I know/understand, there is no way they would use a text editor to edit CellML files for instance). To make COR user friendly involved associating .cml files to COR, because all the users have to do to open a CellML file is, for instance, to double click on it rather than opening a program, then opening a CellML file. It may not be too much to do the latter, but why not make the user's life easier if all that takes is associate an extension to a particular program?
By having only a more generic file extension, we encourage software developers not to use the file extension to determine whether they should open a certain file, and instead look at the MIME type (where available) and/or the XML namespace.
Yes, that could easily be done, but... :) Best regards, Alan. -- University of Oxford, Department of Physiology, Anatomy and Genetics Sherrington Building, Parks Road, Oxford, OX1 3PT, England http://noble.physiol.ox.ac.uk/people/agarny/