[cellml-discussion] Review solicited forapplication/cellml-1.0+xmlandapplication/cellml-1.1+xml

[Andrew Miller]

Quoting Matt Halstead <matt.halstead at auckland.ac.nz>:

> Just to add my two cents worth.
>
> I think a single content-type would be fine in practice. It basically
> gives us the first and rather important filter that plants us in the
> CellML domain. I think from then on we are free to implement any
> services we want that allow an application to probe a piece of content.
>
> This discussion seems to be mixing some interpretations of the
> extensibility and backwards compatibility of XML standards with the
> extensibility and backwards compatibility of the model language and
> rules represented by the CellML/XML. I see a similar problem with
> XMI, essentially one is free to implement an unlimited array of
> metamodels - e.g. UML (and versions of those therein). I can't
> imagine them wanting to support a content type for every utility of
> XMI. At present I don't even think XMI has its own mime-type.

I'm not sure that is a parallel - only backwards incompatible changes to XMI
itself(I am not sure if there have ever been any) would need new MIME types,
not changes to the metadata representation on top.

Essentially, in the CellML case, we have three layers:
1) XML / XML infoset
2) CellML (data)
3) RDF metadata and extension elements. (metadata and extension information)

We can consider 1 stable for all intents and purposes.
2 is less stable(new specifications are rare, but when they do happen, will
break backwards compatibility).
3 is completely unstable, as arbitrary organisations can define new
metadata/extension elements at any time. However, these changes do not break
backwards compatibility for other metadata, or 'layer 2 compatibility'.

I don't think anyone is proposing a new media type every time layer 3 changes,
which is roughly equivalent to the new media type for every XMI example.

However, a new media type layer 2 changes seems sensible, and within the normal
reasons for defining media types(i.e. a new incompatible format).

>
> With CellML, the kind of backwards compatability we would break by
> adding new structures are nearly always because the mathematical
> model without these becomes unsound and so a piece of software
> reading only say CellML 1.0 will likely produce an invalid
> mathematical model. There are other axis to this; for example, the
> mathematical formulation of the model. At present we leave it up to
> the software to guess (by reading the model) or we simply assume it
> is limited to sets of ordinary differential equations in R.H.S form.

MathML expressions are supposed to be declarative, rather than procedural, and
as such, the core model does not define how software is supposed to evaluate
it. Therefore, I don't believe that it makes sense to define new media types
based on the usual way of evaluating a model(i.e. having a
application/cellml-1.1+xml type is quite distinct from having a
application/cellml-1.1-system-of-odes+xml type, because the former is
describing the format in which a model is in, while the latter is abusing media
types to make a suggestion to certain types of software as to how the content
should be used).

> This is an axis that we need to provide details on in the metadata
> and provide a webservice for, so that applications can in the future
> query such details to see if they can actually make use of them. Kind
> of like querying an XMI file to see if it is the right version of UML
> for your needs.

I agree that information on the evaluation of models should be in the metadata,
but I wouldn't extend this to the version of CellML, as the metadata is(at
least conceptually) built on top of CellML, and so requires CellML to be
working first.

>
> I don't see the problem (and I see it as more flexible) to provide a
> web service for CellML model content that returns the cellml versions
> that it can be represented in soundly and that offers to return the
> model in whatever form is requested. A classic example is someone
> wanting us to return a model in CellML 1.0 form that was modelled
> using CellML 1.1 (that has the imports structure). We know that this
> is a simple flattening to get it into 1.0 form and can do this for
> the requester.

I cannot think of a way to do this(robustly, i.e. allowing for fallback on
earlier versions if a later one is not available) in one round-trip without
either adding a new header(not good for web-based applications), adding extra
information to the response entity body on top of the XML, or checking the
namespace of the response.

It seems unwise to define our own non-standard content-negotiation protocol
based on URL mangling(especially if it adds round-trips to the protocol) when
there is a perfectly good one in HTTP. Of course, repository software which
uses Accept: headers for content negotiation could still allow this to be
overriden by query parameters on the URL, to allow the desired model to be
downloaded and         saved in a CellML-unaware browser for later use.

>
> It does mean that an existing piece of software needs to be upgraded
> to manage the handshake, but it is just as likely it needs to be
> upgraded to now send requests using the new content-type it wanted to
> ask for; so I don't really see much of an invasion on old software in
> those cases.

Without knowing what protocol you had in mind, it is hard to compare this with
the Accept: situation, but with accept and Content-Type headers:
1) You can just give one URL to everyone, e.g.
http://www.example.org/repository/MyFavouriteModel.xml
  a) Users with a CellML unaware browser can visit that file an get a CellML
     file(repository decides what version they want). The browser will send a
     single request and get the file back. If the user has set up 'helpers' or
     similar in their browser, a version appropriate one will be launched
     based on the Content-Type.
  b) Tools which only support some versions of CellML send a request, and get
     their preferred version(if the repository knows how to convert to that
     version). The tool knows what version it got from the Content-Type header,
     and if it got a version it doesn't support, can give an error advising
     the user.
  c) Putting XML files on a static web-server still works(provided that the
     tools can handle CellML documents with text/xml or application/xml media
     types).
  d) Only one round trip required, with no non-standard/extension headers.

Best regards,
Andrew Miller


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.