Re: Wish for MathML 3: version attribute

Bert Bos wrote:
>
> Robert Miner wrote:
>> I also support this.  I don't think it will be controversial.
>
> Well...
>
> If we want MathML2 and 3 to co-exist (rather than recommend everybody to
> upgrade to 3) and the two versions require different implementations,
> then the difference should be expressed in the MIME type, by means of a
> new identifier or a parameter. Otherwise the client cannot tell the
> server what it supports and the server cannot give the client what it 
> needs.
Although the IETF types community does not seem to favour registering a
new media type (or even having a version parameter) on documents like
this. See the thread when I tried to register different MIME types for
different versions of CellML:

http://www.alvestrand.no/pipermail/ietf-types/2006-April/001700.html

In the end, everyone was happy with using one MIME type, a different
namespace for each version, and defining an umbrella specification to
which all versions of CellML comply which essentially describes how the
version is encoded in the namespace.

My suggestion relating to content type negotiation was also
controversial:
http://www.alvestrand.no/pipermail/ietf-types/2006-April/001706.html
>
> Even if the server only has one version of the document, it would be
> wasteful to send it to a client that in the end cannot handle it.
>
> Also, we have to see what existing version-2 clients do with a version
> attribute. If they don't stop on seeing the attribute but continue
> parsing anyway, the attribute has no use.
>
> Probably, there are also quite a few documents that would be valid in
> both MathML2 and MathML3, apart from that version attribute. The version
> attribute would require you to make one file for old clients and another
> for new ones. Keeping the version information outside the document
> avoids that.
>
> In general, version information (in whatever form) embedded in the
> document itself is not useful on the Web. Either the format has built-in
> forward and backward compatibility (old implementations can do something
> useful with new documents and vice versa), or it is in fact two
> different formats and their identifiers should be available as MIME
> types outside the document.
>
> HTML has long hesitated over this. The official specification has until
> now had version information in the document, but implementations ignored
> it. HTML5 therefore looks set to abandon the version info.
>
> CSS has never had version information and has always tried to be
> forwards and backwards compatible. Sometimes people ask for version
> information, but when questioned, it always turns out that what they
> really mean is a way to target a particular browser. Version info
> wouldn't help, because there is no specification that corresponds to a
> particular browser, if only because there is no specification that
> describes the bugs in browsers.
>
> (There is one counter-argument against new MIME types and that is that
> authors sometimes don't have control over the MIME types of their Web
> server, because their ISP is of too low quality. Some browsers therefore
> don't rely on the lesser known MIME types, but instead use content
> sniffing for commonly mislabeled types, i.e., they download the document
> and try to guess its type from the content.)
>
> I haven't made a list of the changes between version 2 and 3, but I'm
> hoping that we can avoid removing features (except for any that never
> worked in the first place) and can thus keep all existing MathML
> documents valid in version 3. The version 2 spec can then be declared
> obsolete and all software has to be upgraded, but all content can remain
> unchanged. There is more content than software and software has to be
> updated regularly anyway. There is no need for a new MIME type or a
> version parameter then.
There will always be software that hasn't upgraded out there. I think it
is simply a fact of life that they won't be able to use new content, and
so having a version attribute might at least allow them to fail more
gracefully at the next upgrade.

Best regards,
Andrew

>
>
>
> Bert

Received on Sunday, 16 September 2007 02:46:49 UTC