Review solicited for application/cellml-1.0+xml andapplication/cellml-1.1+xml

[Andrew Miller]

Quoting Mark Baker <distobj at acm.org>:

> On 4/11/06, Andrew Miller <ak.miller at 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.