Quoting Mark Baker <distobj@acm.org>:
On 4/11/06, Andrew Miller <ak.miller@auckland.ac.nz> wrote:
I think that support for each individual version of CellML is quite independent.
That wasn't the impression I got from your other message, because you said;
"I am not aware of anyone supporting 1.1 and not going to the extra effort to support 1.0." The reverse is not true, however.
You did add though, "However, this may not continue for future versions." but I don't see why that would be the case. Don't get me wrong, it's a fine goal, but IME, it happens only when the design of the format explicitly supports it, and AFAICT, CellML doesn't (more below)
[...]
I think that it would give software a lot more flexibility if there was either a version parameter, or a media type. This would allow scripts which serve CellML documents over HTTP to use content-type negotiation to determine which version of the CellML document to send. For example, a client might send
GET /models/SomeModel.xml HTTP/1.1 Host: www.example.org Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml; q=1
CellML is 2.5 years old.
I don't mean to pick nits, but to avoid misinformation I will note that CellML 1.0 was frozen on 10 August 2001.
And since, AFAICT, there's no existing CellML media types, I presume this kind of negotiation doesn't happen already? Do you have any reason to believe it would occur if separate media types were registered?
Certainly it wouldn't be hard to implement, and so the availability of commonly agreed upon MIME types would encourage repository software to implement content negotiation(at which point software vendors would also do the same).
Earlier you wrote;
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.
I would expect that wasn't necessarily the case. Does it not depend on the feature? I would think that there are probably features which can be added in such a way that it's safe for processors which don't recognize them to simply ignore them (so called "must ignore" rule), no?
CellML provides for arbitrarily extensible RDF, as well as extension elements, that is, elements in a namespace other than the CellML, MathML, or RDF namespace. The must-ignore rule applies to unrecognised extension elements or RDF predicates. However, the content of these extension elements/RDF graphs is not described in the CellML specification, but rather in separate specifications defined either by the CellML team or separate organisations. CellML itself is intended to be domain-neutral; that is, it only describes the mathematical model. Therefore, by exclusion, a change in CellML version means a change in the representation of the mathematical model, and that precludes forwards compatibility.
This is how extensibility is typically managed on the Internet and the Web; by designing formats which can accomodate some kinds of extensions in order to enable a more graceful rollout, i.e. not requiring simultaneous software upgrades. I would strongly recommend that you consider this approach for the next version of CellML.
I initially wrote a proposal to use namespace mixing for future versions of CellML, but after discussion, the conclusion was reached that namespace mixing would not be sufficient to preserve compatibility, due to the nature of mathematical models, and so it would be better to deliberately break compatibility rather than let software attempt to read a model which it cannot completely understand, and potentially give wrong results. As I said above, the design of CellML is such that all information which software packages do not have to understand is moved into RDF metadata or extension elements, which are defined separately. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.