Chronological Thread 

< Chronological >      < Thread >

---

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

---

• [cellml-discussion] Review solicited forapplication/cellml-1.0+xmlandapplication/cellml-1.1+xml, Andrew Miller, 04/12/2006
  • [cellml-discussion] Review solicited forapplication/cellml-1.0+xmlandapplication/cellml-1.1+xml, Matt Halstead, 04/12/2006
    • [cellml-discussion] Review solicited forapplication/cellml-1.0+xmlandapplication/cellml-1.1+xml, Andrew Miller, 04/12/2006
      • [cellml-discussion] Review solicited forapplication/cellml-1.0+xmlandapplication/cellml-1.1+xml, Matt Halstead, 04/12/2006

---

Archive powered by MHonArc 2.6.18.