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

David, Math WG, thanks for the response.

Embedded in the message are my responses to your changes. Note others
of the HTML WG may have additional responses, though we all realize
that you must have all responses in this week.

>
> 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
>
>
> >
> > 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.

Unless anyone has any other questions or comments, you've addressed
our concerns.

>
> 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.
>

No, this is fine.

>
>
> > 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.
>

Yes, the language is fine.

> > 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.
>

Unless others express a new comment or concern, you've addressed our concerns.

> >
> > 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.
>
>

Again, unless someone provides a new comment or concern, this
addresses our concerns.

> >
> > 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
>
>
>
>

Thanks, unless there are new comments or concerns, this should address
our concerns.

> >
> >
> > 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.
>

Thanks for the split. Note that section 6.4.2 has a typo, ffer rather
than offer.

A reference back to HTML5 and a note for people to be aware of
differences sufficiently answers the concerns. Thanks for doing this.


> 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.
>
>

Thanks for the clarification. I believe your response answers our concerns.

>
> >
> > 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
>
>

Thanks for the fix.

>
> >
> > 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.
>
>

I believe Philip Taylor may have had additional comments on this[1].
If he doesn't have any other concerns, this should be sufficient
response to our concerns.

> >
> > 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.

I believe the concerns were that you used my:background and my:color
as a generic use of namespaced attributes. But by them showing up in
the index, they could lead people to believe they are formally defined
namespaced attributes, defined for some reason in the specification.

However, this isn't an error, more a comment, so no action is required
for this concern.

David, thanks again for your and the Math WG's response to these concerns.

>
> David Carlisle
> For the Math WG
>


Shelley

Received on Monday, 23 November 2009 01:52:00 UTC