[MathML3-last-call] comments from HTML WG

[Shelley Powers-2]

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.

The MathML href attribute is now, by default, associated with the
MathML namespace. But this isn't specifically stated in the document,
and someone reading both may become confused, and assume they have to
use xlink:href with MathML embedded in HTML5. The document may want to
demonstrate how href can be used with embedded MathML in the document
section detailing MathML embedded in HTML.

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?

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

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


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.

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.

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

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.

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?


Other, general comments:

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

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?

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.

Shelley Powers
HTML WG

[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

[Patrick Ion]

On 06/11/2009, at 7:18 AM, Shelley Powers wrote:

> 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.
Dear Shelley,

Thank you, and the HTML WG, for all the effort that you have put into
responding to our call for comments on what is not a small spec.
It is very important to us that MathML can operate well with HTML5.

The Math WG will respond formally with suggested dispositions in short
course. But though you have very usefully pointed out some things
that we'll correct, it seems happily that there will be nothing that
we cannot adjust to our mutual WG satisfaction.  I look forward to our
having done that.  I expect to be able to make some explanatory
remarks at the HTML WG session this afternoon here in Santa Clara.

We continue wish the HTML5 effort success in your own very large task.

All the best

       Patrick Ion
       Co-chair Math WG

[Joe D Williams]

Great report, Shelley.
The group and editor were very receptive.
I would expect to get comments on these comments.
Thanks Again and Best Regards,
Joe

----- Original Message -----
From: "Shelley Powers" <shelley.just@...>
To: <www-math@...>
Cc: "HTMLWG WG" <public-html@...>
Sent: Friday, November 06, 2009 7:18 AM
Subject: [MathML3-last-call] comments from HTML WG

> 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.
>
> The MathML href attribute is now, by default, associated with the
> MathML namespace. But this isn't specifically stated in the
> document,
> and someone reading both may become confused, and assume they have
> to
> use xlink:href with MathML embedded in HTML5. The document may want
> to
> demonstrate how href can be used with embedded MathML in the
> document
> section detailing MathML embedded in HTML.
>
> 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?
>
> 3. If the UA supports both, what should happen when both are
> specified
> on one element?
>
> 4. We're also curious as to why the new href attribute takes a URI
> rather than IRI?
>
>
> 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.
>
> 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.
>
> In addition, there are also, currently, DOM namespace handling
> differences associated with MathML pasted into HTML, as compared to
> MathML pasted into XHTML.
>
> 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.
>
> 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?
>
>
> Other, general comments:
>
> 7. In the element listing [2] you show an element labeled td, but
> the
> link associated with it leads to a section describing an element
> labeled mtd. Possible typo?
>
> 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?
>
> 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.
>
> Shelley Powers
> HTML WG
>
> [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]

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

[Philip Taylor-5]

(Not speaking on behalf of anyone or suggesting any spec changes, just
commenting on a few things I saw here...)

David Carlisle wrote:
>> 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)

Using CSS3 Color could add RGBA functionality, which would be new. (Not
saying it's necessarily a good idea, though!)

> and typically isn't currently supported by MathML2 systems.

SVG colors seem to be supported by Firefox 3.5:
data:application/xml,<math%20xmlns="http://www.w3.org/1998/Math/MathML"><mi%20mathcolor='tomato'>Test</mi></math>
(I can't say anything about other MathML systems, though.)

> 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

The obsoleteness is about the attributes and the parsing algorithm,
rather than about the colours - that part of the spec is needed for
cases like <body bgcolor="cheese"> (a nice greenish yellow colour, since
it's parsed like #c0ee0e (for legacy reasons), and it's non-conforming
anyway because bgcolor is never allowed).

As far as I can see, the only place HTML5 uses colours in a non-obsolete
fashion is for <canvas>, and there it refers to CSS3 Color for the full
list of colour types and keywords. All other uses of colour in a web
browser are just CSS, so HTML5 is not involved in the definition of
that; browsers largely follow CSS3 Color there.

--
Philip Taylor
pjt47@...

[Shelley Powers-2]

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

[Patrick Ion]

Thank you very much, Shelley, for your answers and for pitching
in to get comments to the Math WG in the  first place.

We'll fix the typo
ffer => offer

Best wishes,

        Patrick


On Nov 22, 2009, at 8:51 PM, Shelley Powers wrote:

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

[David Carlisle]

Shelley, thanks for the speedy feedback, it's really appreciated


>....... Note that section 6.4.2 has a typo, ffer rather
> than offer.


Hmm I think I'm to blame there, sorry:-) Thanks for catching that.


fixed in sources: (and the generated draft updated)

$ cvs commit -m "ffer" world-interactions.xml
Checking in world-interactions.xml;
/w3ccvs/WWW/Math/Group/spec/xml/world-interactions.xml,v  <--  world-interactions.xml
new revision: 1.68; previous revision: 1.67
done



David

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