
Quoting Larry Masinter <LMM@acm.org>:
While CellML versions are not substantially different from each other in terms of the XML element localNames, the changes between 1.0 and 1.1(and likely any future versions) will make backwards compatibility for impossible for most, if not all, CellML processing tools. As such, a new media type for each version is justified. Similarly, the version parameter and the section on determining the version from the XML has been dropped. Both versions of the CellML specification are now referenced as normative references.
I went back and re-read the comments you got, and I think you may have interpreted them incorrectly. I think you were being advised to drop the version parameter, not to register two different media types.
The way that you tell the versions apart is to look inside the documents themselves. That was the original proposal, although there were two messages which disagreed with this idea, if the documents used different namespaces and so were incompatible.
The approach of registering a new media type every time there's an incompatible change isn't consistent with current practice, and isn't particularly scalable, so I'm uncomfortable setting a precedent that every version of a format should get a different type.
Although there is probably little difference between making a new incompatible version, and making a new format with a completely different name, and so one could argue that it would be better to be consistent. That said, the issues here are quite unique to CellML, as mathematical models are much more sensitive to missing information than most types of documents(i.e. if a program understands some but not all of the mathematics, it is likely to be unable to do anything meaningful).
Are you saying CellML 1.1 readers can't also read 1.0?
Most CellML 1.1 software available now also supports CellML 1.0, due to deliberate support for both by the programmer, rather than any feature of CellML.
Or that future CellML versions will also be incompatible? There are no drafts of future versions at the moment, but it is likely that they will add features which mean that CellML 1.0 and CellML 1.1 processing software cannot reliably utilise documents encoded in them.
Is 1.0 deprecated in favor of 1.1, or do you intend to use both forever? The CellML team has not officially deprecated 1.0, although we recommend that all new software support both CellML 1.1 and CellML 1.0. There is still a lot of software available which does not support CellML 1.1, and so models designed to work with these software packages need to be written in CellML 1.0(although it is possible to automatically 'flatten' models written in CellML 1.1 into CellML 1.0 models, with a loss of some variable naming information(due to possible name conflicts) and conceptual elegance, and an increase in file size). CellML 1.0 documents can be converted into CellML 1.1 documents simply by changing the namespace.
Why not just register CellML 1.1 and recommend that people not use CellML 1.0, if 1.1 replaces 1.0?
The problem with this is that there are many CellML 1.0 documents already in existence, and it is likely that they will persist for quite some time. It is not feasible to translate these into CellML 1.1, as this will break existing CellML 1.0-only software. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.