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

[Matt Halstead]

On 12/04/2006, at 3:02 PM, Andrew Miller wrote:

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

I think there is a strong parallel. XMI is an XML representation of  
MOF models. MOF is a metamodel for creating other modelling languages  
such as UML.  CellML is a metamodel for creating mathematical models,  
CellML/XML is the XML representation of this. I believe MOF/XMI have  
similar problems in their evolution as does CellML.


>
> Essentially, in the CellML case, we have three layers:
> 1) XML / XML infoset
> 2) CellML (data)

By this you mean the CellML metamodel itself?

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

I don't see that my XMI example has anything to do with 3.


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

I think we have seen this is impractical from the mime type group and  
I think the relationship between future versions of CellML and  
current ones are complex but probably quite simple to produce  
transformations between without loss of meaning.


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

I was suggesting that the backwards compatibility that we most need  
to consider is the modelling constructs and the semantics of these:  
i.e. the metamodel we call CellML. Adding imports in CellML 1.1 has  
broken backwards compatibility because the structure of the model is  
not complete when interpreted as CellML 1.0; and CellML parsers  
trying to treat it as 1.0 will probably choke on the imports - which  
is a good thing in my mind because it is a well placed exception they  
need to handle. I don't believe we need seperate mime-types for these  
kinds of breakage;

The Math axis was simply pointing out that we already need to offer  
services at the metadata level that relates to the soundness of  
interpreting the mathematics declared within the model. In CellML -  
like MOF/XMI - the soundness of the resulting mathematical model is  
also tied to a complete and accurate interpretation of all CellML  
domain information within the model; in this context the difference  
between CellML 1.0 and 1.1 is not the difference in format but the  
difference in the semantics - which should be provided through a  
metadata interface. It is at this level also that someone should  
negotiate a conversion between versions because the reason's why a  
conversion is or is not possible can be conveyed through metadata  
responses instead of some http error code.


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

We are in essence talking only about the handshake over HTTP for  
CellML model data. The version information should be in the document  
within the CellML namespace, I'm not suggesting otherwise, but I  
think the handshake to figure out just what is available for a given  
model is a little more complicated than "I want 1.0 or 1.1", it's  
more in line with Semantic Web Services.


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

I wasn't talking about fallback.

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

why one round trip? that seems rather old-fashioned.


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

Who said anything about URL mangling?


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

I think you have assumed too much about how a request would be  
parameterised and implemented.


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

I am trying to say if we introduce a Mime type now, there are  
currently no pieces of software that know what to do with it - so  
these will need to be modified to be interested in mime type or they  
will remain uninterested in mime type and break in a good way when  
they are given a newer version of CellML. In these cases it is good  
not to shift things like imports into another namespace because we  
want them to break, and really, mime type has no use whatsoever.


> 1) You can just give one URL to everyone, e.g.

I never suggested changing the URL.

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

What do you mean by a version appropriate one? I can't imagine having  
two applications that do the same thing for opening the different  
versions, conversely, I don't want to be forced into using one of two  
different applications solely because of what version it is. But I  
really don't know what you mean here.


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

That's where I am saying that there is more information they are  
probably interested in providing and getting than just the version of  
CellML; for instance they will probably need to know what formulation  
the math is in, or at least grouping. It's kind of like UML, if there  
was a Mime-type for XMI, then if it followed your rules it would need  
to change it's mime-type if MOF evolved some new structures, but all  
along the way, the agent really wanted to know if the model was a UML  
model or not, and as MOF suggest, there is scope for translations  
between data expressed in different MOF derived model languages. A  
mime-type can't hope to convey all this, plus carry the more  
complicated information required to negotiate the appropriate format  
to return.


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

This will always still work. However, the agent figuring out which  
one to get will already have decided it needs a particular CellML  
version and have the correct URI for it. The OS of the agent can read  
that it is a cellml mimetype and handle it how ever it decides it  
wants to, and would give it an enormous benefit of filtering of  
potential applications than if it were just text/xml - which really  
is all we are trying to achieve with this Mime-type submission.

>   d) Only one round trip required, with no non-standard/extension  
> headers.

Not suggesting extension headers. I'm not too sure why one round trip  
is so important. I would actually be rather annoyed these days if any  
of new applications didn't even do a HEAD on a resource before making  
the actual payload request.


>
> Best regards,
> Andrew Miller
>


cheers
Matt


>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion