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

Quoting Matt Halstead <matt.halstead@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@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion