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

Larry Masinter LMM at
Tue Apr 11 02:14:08 CEST 2006

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

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.

Are you saying CellML 1.1 readers can't also read 1.0?
Or that future CellML versions will also be incompatible?
Is 1.0 deprecated in favor of 1.1, or do you intend to use
both forever?

Why not just register CellML 1.1 and recommend that people
not use CellML 1.0, if 1.1 replaces 1.0?


More information about the Ietf-types mailing list