Comments solicited on application/cellml+xml

Eric Prud'hommeaux eric at w3.org
Tue Mar 28 18:48:25 CEST 2006


On Tue, Mar 28, 2006 at 07:50:01AM -0500, Mark Baker wrote:
> On 3/27/06, Andrew Miller <ak.miller at auckland.ac.nz> wrote:
> > Dear all,
> >
> > I am proposing that the MIME media type application/cellml+xml be used for
> > CellML documents.
> >
> > Please see the Internet draft draft-miller-media-type-cellml-00.txt, available
> > at http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-00.txt,
> > for the full registration.
> 
> Some comments ...
> 
> Section 3, last paragraph.  I consider the versioning strategy you
> define there to be bad practice and so would recommend against it.  It
> appears to say that the next incremental version of CellML will use a
> new namespace, which would make it incompatible with existing
> processors.  Plus, if some future change is significant enough to make
> breaking backwards compatibility necessary or desirable, a new media
> type seems a better option to me.

If you assume the document to be self-describing, I would expect the
namespace to change to prevent older implementations from processing
data that is not backward compatible. If there is only one namespace,
it should change any time the media type needs to change.

I would change the "software SHOULD check the namespace" to a MUST. If
you are feeling ambitious, establish some protocol like:

  CellML processing software MUST check the namespace of 
  *every* element in order to determine whether or not they
  have the capability to process a given document. If the
  software is not able to process the element, it must ignore
  the element, as well as any data within that element.

This more fine-grained versioning approach would allow you to add new
data in a new namespace and have older processors interpret the subset
that they are programmed to process. The current approach of changing
the namespace on the root element would still have the same effects.

Checking every namespace is consistent with conventional XML practice.

> Section 4.  Many media types have thought they needed some kind of
> "version" parameter, but in practice, it's never or rarely used.  e.g.
> text/html had "level", and later, "version", and neither saw
> widespread use.  The reason, I believe, is because the media type
> (minus parameters) is a name that identifies not just a particular
> data format, but a series of compatible formats.  Consider that
> text/html was used for HTML 2.0/3.2/4.01.

+1

> Section 4.  I'd suggest picking a CellML-specific file extension,
> given that a lot of Web servers are configured to send ".xml" files as
> either text/rss, application/xml, or application/rss+xml.

+1
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric at w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20060328/4cdaf258/attachment.bin


More information about the Ietf-types mailing list