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

[Mark Baker]

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."

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.  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?

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?  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.  In
the meantime though, I still think a single media type is your best
bet based on the information you've provided us.

Cheers,

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca