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

Andrew Miller ak.miller at auckland.ac.nz
Tue Apr 11 02:45:30 CEST 2006


Quoting Larry Masinter <LMM at 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.


More information about the Ietf-types mailing list