Review solicited for application/cellml-1.0+xml and application/cellml-1.1+xml
Hi all, I have produced a revised Internet draft, http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-01.txt, following the earlier draft for the registration of application/cellml+xml reviewed on this list. This draft replaces the MIME type being registered, application/cellml+xml, with two MIME types application/cellml-1.0+xml and application/cellml-1.1+xml, based on the recommendations of several ietf-types list members. While CellML versions are not substantially different from each other in terms of the XML element localNames, the changes between 1.0 and 1.1(and likely any future versions) will make backwards compatibility for impossible for most, if not all, CellML processing tools. As such, a new media type for each version is justified. Similarly, the version parameter and the section on determining the version from the XML has been dropped. Both versions of the CellML specification are now referenced as normative references. There was a recommendation on the list that a file extension other than .xml be used for CellML files. This has been discussed with the CellML community on the CellML mailing list, and at the last (and earlier) CellML meetings. However, the consensus was that we should keep the convention of using .xml, as this is currently in wide use. A lot of CellML content currently being served is done by scripts, which can arbitrarily set the MIME type. Most other CellML content served over HTTP would be in its own directory, and so mechanisms like .htaccess(or content based type determination) supported by most popular webservers will be available. In addition, it is probably better that existing software be able to at least determine that it is an XML file, and so using an XML extension will result in text/xml or application/xml. As such, the section on File extension(s) has been left unchanged. Due to the fact that the names of MIME types have changed, I am restarting the two-week review period from today. If there are no new objections, I will submit the document for IESG approval on the 25th April, 2006. Please Note: cellml-discussion@cellml.org is a public list for the CellML community, but only accepts postings from list members. I am on the cellml-types mailing list, and will forward any responses posted there to the cellml-discussion list. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
While CellML versions are not substantially different from each other in terms of the XML element localNames, the changes between 1.0 and 1.1(and likely any future versions) will make backwards compatibility for impossible for most, if not all, CellML processing tools. As such, a new media type for each version is justified. Similarly, the version parameter and the section on determining the version from the XML has been dropped. Both versions of the CellML specification are now referenced as normative references.
I went back and re-read the comments you got, and I think you may have interpreted them incorrectly. I think you were being advised to drop the version parameter, not to register two different media types. The way that you tell the versions apart is to look inside the documents themselves. The approach of registering a new media type every time there's an incompatible change isn't consistent with current practice, and isn't particularly scalable, so I'm uncomfortable setting a precedent that every version of a format should get a different type. Are you saying CellML 1.1 readers can't also read 1.0? Or that future CellML versions will also be incompatible? Is 1.0 deprecated in favor of 1.1, or do you intend to use both forever? Why not just register CellML 1.1 and recommend that people not use CellML 1.0, if 1.1 replaces 1.0? Larry
Quoting Larry Masinter <LMM@acm.org>:
While CellML versions are not substantially different from each other in terms of the XML element localNames, the changes between 1.0 and 1.1(and likely any future versions) will make backwards compatibility for impossible for most, if not all, CellML processing tools. As such, a new media type for each version is justified. Similarly, the version parameter and the section on determining the version from the XML has been dropped. Both versions of the CellML specification are now referenced as normative references.
I went back and re-read the comments you got, and I think you may have interpreted them incorrectly. I think you were being advised to drop the version parameter, not to register two different media types.
The way that you tell the versions apart is to look inside the documents themselves. That was the original proposal, although there were two messages which disagreed with this idea, if the documents used different namespaces and so were incompatible.
The approach of registering a new media type every time there's an incompatible change isn't consistent with current practice, and isn't particularly scalable, so I'm uncomfortable setting a precedent that every version of a format should get a different type.
Although there is probably little difference between making a new incompatible version, and making a new format with a completely different name, and so one could argue that it would be better to be consistent. That said, the issues here are quite unique to CellML, as mathematical models are much more sensitive to missing information than most types of documents(i.e. if a program understands some but not all of the mathematics, it is likely to be unable to do anything meaningful).
Are you saying CellML 1.1 readers can't also read 1.0?
Most CellML 1.1 software available now also supports CellML 1.0, due to deliberate support for both by the programmer, rather than any feature of CellML.
Or that future CellML versions will also be incompatible? There are no drafts of future versions at the moment, but it is likely that they will add features which mean that CellML 1.0 and CellML 1.1 processing software cannot reliably utilise documents encoded in them.
Is 1.0 deprecated in favor of 1.1, or do you intend to use both forever? The CellML team has not officially deprecated 1.0, although we recommend that all new software support both CellML 1.1 and CellML 1.0. There is still a lot of software available which does not support CellML 1.1, and so models designed to work with these software packages need to be written in CellML 1.0(although it is possible to automatically 'flatten' models written in CellML 1.1 into CellML 1.0 models, with a loss of some variable naming information(due to possible name conflicts) and conceptual elegance, and an increase in file size). CellML 1.0 documents can be converted into CellML 1.1 documents simply by changing the namespace.
Why not just register CellML 1.1 and recommend that people not use CellML 1.0, if 1.1 replaces 1.0?
The problem with this is that there are many CellML 1.0 documents already in existence, and it is likely that they will persist for quite some time. It is not feasible to translate these into CellML 1.1, as this will break existing CellML 1.0-only software. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 4/10/06, Larry Masinter <LMM@acm.org> wrote:
The approach of registering a new media type every time there's an incompatible change isn't consistent with current practice, and isn't particularly scalable, so I'm uncomfortable setting a precedent that every version of a format should get a different type.
FWIW, I think it's the practice of introducing incompatible changes which doesn't scale, but that does seem to be what CellML has done, and may continue to do (as Andrew notes). It sounds a bit like the RSS situation, where "supporting RSS" necessarily means supporting several specifications which are only loosely compatible. Will "supporting CellML" mean supporting all versions of CellML? It sounds like it might be, based on Andrew's answers to your questions. In that case, I agree that a single media type is appropriate. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Quoting Mark Baker <distobj@acm.org>: ...
Will "supporting CellML" mean supporting all versions of CellML? It sounds like it might be, based on Andrew's answers to your questions. I think that support for each individual version of CellML is quite independent.
In terms of forwards support, there are many CellML 1.0 only applications, and should a future version of the specification be released, there will be applications which don't support that. In terms of backwards support, software which supports CellML 1.1 can easily support CellML 1.0, just by looking for elements of a different namespace. I am not aware of anyone supporting 1.1 and not going to the extra effort to support 1.0. However, this may not continue for future versions. For example, cellml:reaction is currently regarded as a mistake, as it mixes domain specific information into otherwise domain-neutral mathematical models(the favoured way to do this is now through metadata, which doesn't prevent domain-unaware software from processing the model). Future CellML specifications may drop cellml:reaction, and software vendors who do not wish to implement this may choose not to support only later versions.
In that case, I agree that a single media type is appropriate. I think that it would give software a lot more flexibility if there was either a version parameter, or a media type. This would allow scripts which serve CellML documents over HTTP to use content-type negotiation to determine which version of the CellML document to send. For example, a client might send
GET /models/SomeModel.xml HTTP/1.1 Host: www.example.org Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml; q=1 and the server could then serve a CellML 1.1 model, if it has one(or can attempt to convert into CellML 1.1 from the version it has), or otherwise serve a CellML 1.0 model. Applications(clients) which don't support 1.1 could request a 1.0 version. This way, the server can provide the best/most elegant model that it can, while still supporting all CellML applications from a single URL. Similarly, users viewing models with their web-browser could configure a bleeding edge application for the latest version parameter/MIME type, and a more established application for older versions. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 4/11/06, Andrew Miller <ak.miller@auckland.ac.nz> wrote:
I think that support for each individual version of CellML is quite independent.
That wasn't the impression I got from your other message, because you said; "I am not aware of anyone supporting 1.1 and not going to the extra effort to support 1.0." You did add though, "However, this may not continue for future versions." but I don't see why that would be the case. Don't get me wrong, it's a fine goal, but IME, it happens only when the design of the format explicitly supports it, and AFAICT, CellML doesn't (more below) [...]
I think that it would give software a lot more flexibility if there was either a version parameter, or a media type. This would allow scripts which serve CellML documents over HTTP to use content-type negotiation to determine which version of the CellML document to send. For example, a client might send
GET /models/SomeModel.xml HTTP/1.1 Host: www.example.org Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml; q=1
CellML is 2.5 years old. And since, AFAICT, there's no existing CellML media types, I presume this kind of negotiation doesn't happen already? Do you have any reason to believe it would occur if separate media types were registered? Earlier you wrote;
There are no drafts of future versions at the moment, but it is likely that they will add features which mean that CellML 1.0 and CellML 1.1 processing software cannot reliably utilise documents encoded in them.
I would expect that wasn't necessarily the case. Does it not depend on the feature? I would think that there are probably features which can be added in such a way that it's safe for processors which don't recognize them to simply ignore them (so called "must ignore" rule), no? This is how extensibility is typically managed on the Internet and the Web; by designing formats which can accomodate some kinds of extensions in order to enable a more graceful rollout, i.e. not requiring simultaneous software upgrades. I would strongly recommend that you consider this approach for the next version of CellML. In the meantime though, I still think a single media type is your best bet based on the information you've provided us. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
GET /models/SomeModel.xml HTTP/1.1 Host: www.example.org Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml; q=1
HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out. The original theory of content negotiation was worked out when the idea of the web was that browsers would support a handful of media types (text, html, a couple of image types), and so it might be reasonable to send an 'accept:' header listing all of the types supported. But in practice as the web evolved, browsers would support hundreds of types of all varieties, and even automatically locate readers for content-types, so it wasn't practical to send an 'accept:' header for all of the types. 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 most common kind of content negotiation uses the 'user agent' identification header, or some other 'x-...' extension headers to detect browser versions, among other things, to identify buggy implementations or proprietary extensions. I think we should deprecate HTTP content negotiation, if only to make it clear to people reading the spec that it doesn't really work that way in practice. Many people seem to use HTTP content negotiation as a motivation for adding 'version' parameters to MIME types or registering new MIME types, with the hopes that the MIME types or parameters would be useful in HTTP content negotiation, and we should warn them that it isn't really productive to do so. That's why it might be useful advice to add to the guidelines for registering MIME types, should those ever be updated. (I think this situation is mainly my fault, fwiw, so: I'm sorry). Larry
Quoting Larry Masinter <LMM@acm.org>:
GET /models/SomeModel.xml HTTP/1.1 Host: www.example.org Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml; q=1
HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out. The original theory of content negotiation was worked out when the idea of the web was that browsers would support a handful of media types (text, html, a couple of image types), and so it might be reasonable to send an 'accept:' header listing all of the types supported. But in practice as the web evolved, browsers would support hundreds of types of all varieties, and even automatically locate readers for content-types, so it wasn't practical to send an 'accept:' header for all of the types.
Although it is certainly a goal(towards which some progress has been made) of the CellML project to enable CellML models to load in a browser so that they can be viewed or run, many CellML tools also download files themselves. Likewise, while CellML models are sometimes placed on static web-servers, they are also commonly served by scripts. This combination makes HTTP content negotiation more useful to CellML tools than it is, for example, to a web-browser.
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.
The most common kind of content negotiation uses the 'user agent' identification header, or some other 'x-...' extension headers to detect browser versions, among other things, to identify buggy implementations or proprietary extensions.
For HTML this is necessary because browsers accept more or less than what the HTML specification allows. CellML is much simpler(although it is true that you can express a wide variety of models in MathML, and tools will not support all of them. However, CellML defines a 'core set' of MathML elements which all tools must support). In terms of returning the correct version, however, content-negotiation seems like a good solution.
I think we should deprecate HTTP content negotiation, if only to make it clear to people reading the spec that it doesn't really work that way in practice.
I'm not sure that content-negotiation is non-useful. After all, HTTP is used for a lot more than just serving HTML documents. BTW I assume you are talking purely about Accept: and not Accept-Language:, as Accept-Language: is widely used by multilingual sites to determine which language to serve.
Many people seem to use HTTP content negotiation as a motivation for adding 'version' parameters to MIME types or registering new MIME types, with the hopes that the MIME types or parameters would be useful in HTTP content negotiation, and we should warn them that it isn't really productive to do so.
That may be true for formats designed primarily to be viewed in web-browsers, but I don't believe that it is true in general.
That's why it might be useful advice to add to the guidelines for registering MIME types, should those ever be updated.
Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
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.
BTW I assume you are talking purely about Accept: and not Accept-Language:, as Accept-Language: is widely used by multilingual sites to determine which language to serve.
Accept-language: doesn't have the same scalability problems that accept: has.
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.
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
To say something in Larry's defense, language negotiation in HTTP works reasonably well (Accept-Language). The list of languages that the average person reads is reasonably small, and most languages only take two (or sometimes three) letters to indicate, so all the information can be put in a header line. Quite a few sites use language negotiation, although there are many more that could use it but don't. It's always good to have a manual way to switch languages, but it's a hassle if the first page on a site is used just to allow a user to select the language if the browser tells the server what the preference is anyway. Most browsers come preconfigured with the Accept-Language set to the language of the browser (user interface) itself, and allow further configurations (adding other languages). Servers also got better, in Apache it was a pain to set up default languages, but now it works much better. For more information, please see the relevant topics at http://www.w3.org/International/resource-index.html#lang. There is also an IETF WG (LTRU) that works on extending the syntax for language tags to e.g. include scripts where necessary. Please check http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt (IESG approved, in RFC Editor queue) and http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt Regards, Martin. At 02:32 06/04/12, Larry Masinter wrote:
GET /models/SomeModel.xml HTTP/1.1 Host: www.example.org Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml; q=1
HTTP content negotiation was one of those "nice in theory" protocol additions that, in practice, didn't work out. The original theory of content negotiation was worked out when the idea of the web was that browsers would support a handful of media types (text, html, a couple of image types), and so it might be reasonable to send an 'accept:' header listing all of the types supported. But in practice as the web evolved, browsers would support hundreds of types of all varieties, and even automatically locate readers for content-types, so it wasn't practical to send an 'accept:' header for all of the types.
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 most common kind of content negotiation uses the 'user agent' identification header, or some other 'x-...' extension headers to detect browser versions, among other things, to identify buggy implementations or proprietary extensions.
I think we should deprecate HTTP content negotiation, if only to make it clear to people reading the spec that it doesn't really work that way in practice.
Many people seem to use HTTP content negotiation as a motivation for adding 'version' parameters to MIME types or registering new MIME types, with the hopes that the MIME types or parameters would be useful in HTTP content negotiation, and we should warn them that it isn't really productive to do so. That's why it might be useful advice to add to the guidelines for registering MIME types, should those ever be updated.
(I think this situation is mainly my fault, fwiw, so: I'm sorry).
Larry
Apparently my message http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html has caused some discussion here and elsewhere, so I thought I should correct myself. I misspoke about 'HTTP content negotiation'. As Martin points out, content negotiation works fine for 'accept-language', and it is frequently used with 'user-agent'. It's only content negotiation based on 'accept:' that has limited applicability, mainly to cases where there are a limited number of choices. And HTTP content negotiation based on MIME types and the 'accept' header wasn't such a bad idea at the time it was introduced into HTTP, because at the time there were relatively few content-types a browser actually could be expected to support. The web at the time was mainly text and HTML. There weren't any IMG tags. (It was also one of the reasons why it wasn't such a bad idea to open a separate TCP connection for every HTTP request, because 'a web page' could be retrieved with a single request.) It was only the introduction of using separate HTTP requests for embedded images (rather than a compound document format), and the explosion of image types and other kinds of embedded content that made using Accept: with a list of content types impractical for the 'web browsing' case (and also required some changes to HTTP for persistent connections.) Larry -- http://larry.masinter.net
Quoting Mark Baker <distobj@acm.org>:
On 4/11/06, Andrew Miller <ak.miller@auckland.ac.nz> wrote:
I think that support for each individual version of CellML is quite independent.
That wasn't the impression I got from your other message, because you said;
"I am not aware of anyone supporting 1.1 and not going to the extra effort to support 1.0." The reverse is not true, however.
You did add though, "However, this may not continue for future versions." but I don't see why that would be the case. Don't get me wrong, it's a fine goal, but IME, it happens only when the design of the format explicitly supports it, and AFAICT, CellML doesn't (more below)
[...]
I think that it would give software a lot more flexibility if there was either a version parameter, or a media type. This would allow scripts which serve CellML documents over HTTP to use content-type negotiation to determine which version of the CellML document to send. For example, a client might send
GET /models/SomeModel.xml HTTP/1.1 Host: www.example.org Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml; q=1
CellML is 2.5 years old.
I don't mean to pick nits, but to avoid misinformation I will note that CellML 1.0 was frozen on 10 August 2001.
And since, AFAICT, there's no existing CellML media types, I presume this kind of negotiation doesn't happen already? Do you have any reason to believe it would occur if separate media types were registered?
Certainly it wouldn't be hard to implement, and so the availability of commonly agreed upon MIME types would encourage repository software to implement content negotiation(at which point software vendors would also do the same).
Earlier you wrote;
There are no drafts of future versions at the moment, but it is likely that they will add features which mean that CellML 1.0 and CellML 1.1 processing software cannot reliably utilise documents encoded in them.
I would expect that wasn't necessarily the case. Does it not depend on the feature? I would think that there are probably features which can be added in such a way that it's safe for processors which don't recognize them to simply ignore them (so called "must ignore" rule), no?
CellML provides for arbitrarily extensible RDF, as well as extension elements, that is, elements in a namespace other than the CellML, MathML, or RDF namespace. The must-ignore rule applies to unrecognised extension elements or RDF predicates. However, the content of these extension elements/RDF graphs is not described in the CellML specification, but rather in separate specifications defined either by the CellML team or separate organisations. CellML itself is intended to be domain-neutral; that is, it only describes the mathematical model. Therefore, by exclusion, a change in CellML version means a change in the representation of the mathematical model, and that precludes forwards compatibility.
This is how extensibility is typically managed on the Internet and the Web; by designing formats which can accomodate some kinds of extensions in order to enable a more graceful rollout, i.e. not requiring simultaneous software upgrades. I would strongly recommend that you consider this approach for the next version of CellML.
I initially wrote a proposal to use namespace mixing for future versions of CellML, but after discussion, the conclusion was reached that namespace mixing would not be sufficient to preserve compatibility, due to the nature of mathematical models, and so it would be better to deliberately break compatibility rather than let software attempt to read a model which it cannot completely understand, and potentially give wrong results. As I said above, the design of CellML is such that all information which software packages do not have to understand is moved into RDF metadata or extension elements, which are defined separately. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
participants (5)
-
Andrew Miller -
Larry Masinter -
Mark Baker -
Martin Duerst -
Matt Halstead