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

[Matt Halstead]

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.

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

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.


cheers
Matt


On 12/04/2006, at 11:10 AM, Andrew Miller wrote:

> Quoting Larry Masinter <LMM at acm.org>:
>
>>>> So content negotiation in practice doesn't use accept: headers
>>>> except in limited circumstances; for the most part, the sites send
>>>> some kind of 'active content' or content that autoselects for  
>>>> itself
>>>> what else to download; e.g., a HTML page which contains Javascript
>>>> code to detect the client's capabilities and figure out which other
>>>> URLs to load.
>>>
>>> The embedding of scripts in CellML is not recommended, not  
>>> defined by any
>>> specifications, not (as far as I know) supported by any software  
>>> packages,
>> and
>>> if vendors do want to support scripts, they should only use it  
>>> express
>>> functions which cannot be represented in MathML, not for content
>> negotiation.
>>> Therefore, scripts are not a viable option for CellML negotiation.
>>
>> If you have a HTML page that includes javascript that asks
>>    IF (browser supports CellML 1.1)
>>             THEN (load URL for cellML 1.1 content)
>>    ELSE IF (browser supports CellML 1.0)
>>             THEN (load URL for cellML 1.0 content)
>>    ELSE
>>        (insert content for 'can't display model')
>>
>> you don't put the Javascript inside CellML, you put it in the
>> HTML code that decides whether or not to load CellML at all.
>
> Given that CellML is supposed to be a language for the interchange of
> mathematical models, I think that requiring an HTML page load just  
> so you can
> detect what CellML version is supported seems like unnecessary  
> overhead, and
> could cause problems for non-browser based tools. Javascript-based  
> detection
> approaches are useful in some contexts, and have been implemented  
> before, for
> web-based interfaces to CellML repository pages intended for  
> interactive users.
> However, HTML is not useful for non-browser based/non-interactive  
> systems(but
> CellML, sometimes combined with HTTP, is useful in these situations).
>
> Best regards,
> Andrew Miller
>
>
> ----------------------------------------------------------------
> 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