W3C home > Mailing lists > Public > www-math@w3.org > January 2000

min/max (Re: MathML2 2nd WD (long))

From: Andreas Strotmann <strotman@nu.cs.fsu.edu>
Date: Tue, 11 Jan 2000 16:04:01 -0500 (EST)
To: David Carlisle <davidc@nag.co.uk>
cc: strotman@nu.cs.fsu.edu, www-math@w3.org
Message-ID: <Pine.GSO.4.10.10001111545050.790-100000@xi.cs.fsu.edu>
> > -- 4.2.4.1 min,max:  the following unique property of min/max is a
> > singularly bad idea and should be removed: 
> 
> There is a general principle of not breaking MathML 1.x as far as
> possible so while we can look at this again, it is harder to get changes
> in this area than to features that are being introduced for MathML2,
> whose syntax is not so finalised.

Well, I guess that means the argument should be more persuasive in this
case.  You could make the feature "obsolete" like the ill-fated <reln>, I
guess.

The problem I pointed out is actually a really bad one, as the feature
makes it impossible (in principle) to derive a correct interpretation for
a MathML content expression using the feature, as I pointed out was the
case in the very example given in the draft.

Now, I'm not harping about the more arcane problems with violations of
compositionality in the int/sum/product operators that I discussed at some
length on this list two years ago.  These are problematic, but still allow
correct interpretation, albeit with more work to do in order to get it
right than would be strictly necessary.  It's something of a taste and
practical issue, and can be "fixed" by proper verbiage in the
specification (hoping that programmers read and implement it carefully
enough;-).

But this particular case is actually *wrong* as it provably defeats the
very purpose of content MathML to support correct automatic
interpretation of the content, as, again, the very example given in the
text shows.  I would argue that this fact alone should argue strongly in
favor of doing away with the "feature" as soon as possible, so that as
little information as possible is produced using MathML with this feature
that requires AI techniques and intelligent guessing to interpret
correctly.

  --  Andreas
Received on Tuesday, 11 January 2000 16:04:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:49 GMT