Re: Wish for MathML 3: version attribute

Sorry to react to such an old thread, but travel kept me from writing an 
answer when the thread was still fresh and I still want people to think 
carefully about what they think a version number in a document actually 
achieves in practice.

As I said in the working group, I won't formally oppose a version 
attribute. Apart from confusing users a little, I think it does no 
harm. (But no good either.)


On Sunday 16 September 2007 06:00, Michael Kohlhase wrote:
> 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.
>
> I am not sure that this even applies to MathML practice, since almost
> always will MathML exist as MathML islands in another XML
> application. So are you suggesting something like
> application/xhtml1.1+mathml3+svg2.1 ?

Something like it, yes. The CDF working group actually decided to 
specify MIME types for compound documents like this:

    application/xhtml+xml; profile="http://www.w3.org/2007/wicd"

That means it is XHTML and, if you must, you can send it to a browser 
that claims to understands XHTML, although it might not render 
correctly. Or you can send those browsers something else (XHTML with 
images, e.g.) and only send this document to browsers that explicitly 
claim to understand the given profile. In that case you're sure it 
renders correctly. (Or at least that the implementer meant to render it 
correctly; you can never exclude bugs.)

(I know the profile name isn't very memorable. I protested against it, 
but, on the other hand, how often do you type a MIME type by hand? And 
the URL does actually lead to a human readable document, though only in 
English.)

This MIME type is for the WICD1 document format, which consists of 
elements from XHTML and SVG. So it's not the right MIME type for 
XHTML+MathML. But, if we lobby hard enough, WICD2 may include MathML, 
and then the MIME type for an XHTML+MathML document would probably be

    application/xhtml+xml; profile="http://www.w3.org/2009/wicd"

> I think that a version 
> attribute in the source makes sense, since then applications can
> tailor the behavior to old versions, somewhat like quirks mode in
> browsers.

What would they do differently? I know there are some deprecated 
elements in MathML3, but those make no difference for an 
implementation. Deprecated elements are still part of the standard and 
must be supported. Are there any elements whose meaning has changed in 
such a way that an author might want to put in a "version=2" to get the 
old behavior back? I don't know of any.

In fact, I claim that such a case should never occur. Either a 
definition was changed because it had an error (in which case nobody 
could use it anyway), or the old and the new definition both make 
sense, and in that case the new definition is really a distinct 
feature, deserving a new name.

Quirksmode is a different phenomenon. It is not to deal with differences 
between versions of HTML or CSS (they are fully backwards compatible), 
but to deal with content that relies on bugs in early browsers. I don't 
know if there is an equivalent for MathML documents, but at least we 
would first need an analysis of what the problems are, exactly, and how 
to recognize offending content. (Quirksmode assumes that all 
HTML documents without a recent DOCTYPE rely on browser bugs; that's 
not always true.)

So I think implementations for version N would treat content for 
versions < N exactly as version N. Remains the question what an 
implementation for version N will do with content for versions > N.

They can either do their best to handle the content anyway, on the 
assumption that 99% of it will display just fine and the user is smart 
enough to make sense of the rest. Or they can refuse to handle the 
content.

In the former case, an author has no reason to put in a version number. 
So let's assume the latter case.

An author who puts in a version > N will soon discover that many of his 
readers can't see what he wrote. He may try to find the lowest version 
number for each of his formulas that still makes them valid. But that 
is not easy to do. However, what *is* easy to do is omit the version 
number altogether. The W3C validator may complain about a missing 
attribute (or maybe not even that) and all implementations will handle 
all formulas to the best of their ability. Some things may not look 
quite right in the oldest tools, but the users of those tools probably 
don't expect anything else.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Tuesday, 16 October 2007 11:41:09 UTC