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@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@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion