Re: [MathML3-last-call] comments from HTML WG

Shelley, HTML WG,

Thank you for your comments.

As noted below we have fixed the definite mistakes that you reported
and have tried to add clarifying text to address the other issues you
raised. The results can be seen at the editors' draft


http://monet.nag.co.uk/~dpc/draft-spec/chapter2.html#fund.attval



> Following are some general comments about the MathML 3.0 draft from
> the HTML WG, particularly as the MathML specification relates to
> current effort with HTML5.  First, though, we wish to extend to the
> Math WG congratulations for reaching this important milestone.
> 
> Related to the addition of the new href attribute[1]:
> 
> 1. The attribute href has been added for use with several MathML
> elements, rather than using xlink:href, from MathML 2.0. However, the
> document states that because of compound document requirements,
> xlink:href can still be used. This could cause confusion when viewing
> the documentation for  MathML as foreign object in HTML5. In the HTML5
> specification, if the href attribute is associated with the XLink
> namespace, it must be given as xlink:href in the document.
> 


Foreign namespaced attributes are allowed in MathML3, as they are in
earlier versions of MathML, so syntactically xlink attributes are allowed
by general principles, but the MathML3 spec is quite explict that href is the
preferred form for use as a hyperlink. We have adjusted the text in
section 6 to make this clearer and to give advice to existing
mathml2+xlink applications.

RCS file: /w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v

revision 1.59
date: 2009/11/18 04:08:00;  author: rminer;  state: Exp;  lines: +19 -14
linking rewrites



> The MathML href attribute is now, by default, associated with the
> MathML namespace. But this isn't specifically stated in the document,

Like all unprefixed attributes it is in no namespace. It is not
associated with the MathML namespace, thus we do not know what
statement you expected to see here, we are assuming no change is
required to the document. If you feel some clarification is needed,
please respond further on this point.



> and someone reading both may become confused, and assume they have to
> use xlink:href with MathML embedded in HTML5. 

xlink:href was only mentioned in passing in one or two places,
discussing differences with MathML2 so we were not sure why you thought
someone would have to use xlink, but as noted above we have
adjusted the wording in section 6.4.2 Linking to try to make this
clearer.

> The document may want to
> demonstrate how href can be used with embedded MathML in the document
> section detailing MathML embedded in HTML.

This section has been rewritten, href should not really need an example,
it takes a URI (LEIRI) as value and is used exctly the same way as a
href in html for example.

> 
> 2. Is the plan to drop support for xlink:href in MathML UAs at some
> point? If not, we're curious as to why the Math WG introduced the new
> attribute?

xlink was not widely supported amongst mathml2 UAs in any case, for
example as far as we can tell it doesn't work in any current browser
implementation of mathml (although it has worked in firefox)

xlink is a separate specification which user agents may or may not wish
to implement, the MathML spec can not say what other specifications
should be implemented by applications. We have revised the text in 6.4.2
to give advice on what an application supporting both xlink and native
mathml linking should do. The issue here though is just the same as in
xhtml, if an application supports xlink and xhtml there is the
possibility of having both href and xlink:href on the same element.



> 
> 3. If the UA supports both, what should happen when both are specified
> on one element?


Formally this is out of scope for MathML, however we have given some
advice that href be preferred in the revised linking section.


> 
> 4. We're also curious as to why the new href attribute takes a URI
> rather than IRI?

Thanks for catching this, we will add some clarifying text.

Most XML related specifications (including XML itself and XSD) as well
as MathML use "URI" (or "URL" in older specs such as XML or MathML1) to
mean essentially what is now known as an IRI (or differing in some edge
cases, a LEIRI). The MathML attributes that are described as type URI
are actually XSD schema typed as xs:anyURI which means that they have a
lexical space of any string and the system is supposed to %-encode any
characters not allowed in URI. Effectively this means that they take an
IRI. We have added wording to the table of common attribute types in
2.1.5 where this attribute type is introduced.

http://www.w3.org/TR/MathML3/chapter2.html#fund.attval

Adding reference for URI to both the current IRI RFC, 

http://www.ietf.org/rfc/rfc3987.txt

and its proposed update

http://tools.ietf.org/html/draft-duerst-iri-bis-07




$ cvs commit -m IRI fundamentals.xml references.xml
Checking in fundamentals.xml;
/w3ccvs/WWW/Math/Group/spec/xml/fundamentals.xml,v  <--  fundamentals.xml
new revision: 1.127; previous revision: 1.126
done
Checking in references.xml;
/w3ccvs/WWW/Math/Group/spec/xml/references.xml,v  <--  references.xml
new revision: 1.90; previous revision: 1.89
done




> 
> 
> Related to the Chapter 6.4, Combining MathML and Other Formats, and
> specific to 6.4.1, Mixing MathML and HTML:
> 
> 5. The specification includes a section discussing MathML and HTML.
> However, the section only references MathML in XHTML. With HTML5,
> MathML can be used in HTML, and there are additional constraints on
> using MathML in HTML, including the fact that the outer math element
> is specified without a prefix (such as m:math, as shown in the
> example), though the use of a namespace and prefix can work with
> XHTML.
> 
> There are other constraints associated with MathML in HTML. Could this
> one section be split in two, with one section detailing MathML in
> XHTML, and one in HTML?
> 
> In particular, HTML allows unquoted attributes, and elements without
> closing tags (if such are given in the list of allowed elements
> without closing tags). These looser specifications also apply to
> foreign
> objects such as SVG and MathML (though user agents are encouraged to
> provide an export facility providing properly formatted XML). However,
> people can paste properly formatted XML into HTML, and it will be
> supported.


The existing MathML+HTML section in chapter 6 has been split into two,
one for XHTML and one for non-xml syntaxes, specifically HTML5.

Note however the MathML specification defines MathML as an XML
application, if other specifications define mathml variants with
different syntax then it is that specification that must specify
the differences. (HTML5 effectively does that by specifying how
the html-like syntax is parsed to an xml dom).



$ cvs commit -m html5 references.xml world-interactions.xml
Checking in references.xml;
/w3ccvs/WWW/Math/Group/spec/xml/references.xml,v  <--  references.xml
new revision: 1.91; previous revision: 1.90
done
Checking in world-interactions.xml;
/w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v  <--  world-interactions.xml
new revision: 1.62; previous revision: 1.61
done



> 
> Pasting MathML into HTML does lead to another issue: the use of
> namespaced attributes. Namespaced attributes can be included in
> MathML, but, currently, the validator does provide a warning for
> namespaced attributes in SVG or MathML when embedded in HTML. The same
> applies to properly formatted XML entities and attributes that might
> be included within the MathML annotation-xml
> element.

The behaviour of namespaced attributes is entirely implementation
defined, they are allowed but no particular behaviour is mandated, so if
for example they were just ignored by HTML systems that would be
conformant, doing more would be helpful to the user, but not mandated.

> 
> In addition, there are also, currently, DOM namespace handling
> differences associated with MathML pasted into HTML, as compared to
> MathML pasted into XHTML.
> 

The MathML3 spec does not discuss the DOM at all, so while this might be
true it does not affect the MathML3 specification. If we decide later to
update the MathML2 DOM to a separate MathML3 DOM specification, this
might become an issue.

> Both the DOM differences and the validator warnings, in addition to
> the syntax differences, such as unquoted attribute values, might be
> surprising and confusing to folks who expect properly formatted XML in
> HTML.
> 

As noted above, the MathML specification only defines the XML syntax.
If other specifications introduce syntactic variants, then any issues
must be addressed in those specifications. However as HTML is an
important special case, a mention of unquoted attributes in html is given
as an example in the new html-specific section in chapter 6.


> 6. The section contains the following passage:
> 
> "To fully integrate MathML into XHTML, it should be possible not only
> to embed MathML in XHTML, as described in Section 6.2.1 Recognizing
> MathML in XML, but also to embed XHTML in MathML. However, the problem
> of supporting XHTML in MathML presents many difficulties. Therefore,
> at present, the MathML specification does not allow XHTML elements
> within a MathML expression, although this situation may be subject to
> change in a future revision of MathML."
> 
> What are the difficulties referenced in the document?
> 
> In particular, the HTML5 parser supports HTML and SVG in <mi>, <mo>,
> <mn>, <ms>, <mtext> and SVG in <annotation-xml>. XHTML and SVG in
> MathML in these places works fine in Firefox and Opera today when
> using application/xhtml+xml. We're curious as to why MathML doesn't
> allow what is, at a minimum, expressible in text/html?
>

the quoted section has been rewritten as that section has been split in
two, as noted above so that HTML and XHTML can be discussed separately.

Also, please refer to the reply given to the I18n group on a similar question.


http://lists.w3.org/Archives/Public/www-math/2009Nov/0010.html

The normative schema for MathML needs to restrict to text in for the
reasons given. XHTML+MathML, being defined by a schema could use a more
open schema that allowed nested XHTML elements. MathML in HTML5, being
defined by the prose text of the HTML5 parse rules is defined by that
specification not by MathML.

It would be entirely wrong for the normative MathML schema to say that
(X)HTML elements are by default allowed inside mtext. MathML as used by
computer algebra systems (for example) probably can not deal with
structured text at all, and docbook+MathML or XSL-FO+MathML (for
example) would typically be processed by systems that could handle
embedded docbook (or XSL-FO) elements in mtext but not HTML. This is why
it needs to be the decision of the person defining the compound document
format (XHTML+MathML or HTML+MathML) whether to allow nested HTML inside
mtext.  Even in a purely HTML+MathML application it isn't always
possible to support nested HTML elements and mandating it would make
some highly used systems non compliant. In a component architecture such
as used by IE, if a different component is being used to render the
MathML, it can not (given current API) easily call back to the host
browser to render nested instances of HTML.



> 
> Other, general comments:
> 
> 7. In the element listing [2] you show an element labelled td, but the
> link associated with it leads to a section describing an element
> labeled mtd. Possible typo?

Thanks for catching this.

That list is automatically generated from the xmlspec markup and it is
highlighting a typo in 3.5.4.2 Attributes  where td was used for
mtd. 


This has been fixed in our sources.

$ cvs commit -m "td to mtd" presentation-markup.xml
Checking in presentation-markup.xml;
/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml,v  <--  presentation-markup.xml
new revision: 1.292; previous revision: 1.291
done



> 
> 8. In the section describing color[3] you reference color names from
> HTML4. Is there a reason MathML doesn't use css3-color SVG color
> keywords instead of HTML4 color keywords?

Initially (MathML1) there was no css3-color or svg.
We did look briefly at extending this list but it wasn't clear that this
would be useful: it doesn't really add any new functionality (since hex
colours are supported) and typically isn't currently supported by
MathML2 systems. HTML5 has these extended color names but introduces
them as 

      "Some obsolete legacy attributes parse colors in a more
       complicated manner,"

which doesn't really encourage these colours to be added as a new feature
to other specs such as MathML3


Adding the long list of X11/SVG colour names to MathML3 at this time
would hurt interoperability with existing MathML systems that do not
support them, and offers no real extra features (as the colours may be
specified using the hex rgb syntax). Supporting the extended list imposes
a non negligable implementation cost on any implementation that is not
hosted in a CSS environment that already supports these colours.


> 
> 9. The index lists two values, my:background and my:color, which are
> also demonstrated in the section to which they're linked. These would
> seem to be from demonstrations of bringing in color or background from
> another namespace. Including them in the index could generate
> confusion.

The index (which is automatically generated) indexes the use of these
attributes. Why do you think it confusing to index an example that is
there? Perhaps you mean that the example is confusing, but if so could
you give some indication of what in particular causes confusion or what
could be changed to lessen the confusion.

> 
> Shelley Powers
> HTML WY
> 
> [1] http://www.w3.org/TR/2009/WD-MathML3-20090924/chapter2.html#fund.globatt
> [2] http://www.w3.org/TR/2009/WD-MathML3-20090924/appendixh.html#index.elem
> [3] http://www.w3.org/TR/2009/WD-MathML3-20090924/chapter2.html#type.color
> 
> 


David Carlisle
For the Math WG






________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

Received on Thursday, 19 November 2009 17:32:33 UTC