* Paul Libbrecht wrote:
The first problem I have with this is that there is no word on what
exactly the various types are for, like if there are any restrictions
on what should be in a mathml-content+xml vs a mathml-presentation+xml
document, or if the types can be used with MathML 2.0.
that is defined in chapter 6:
http://www.w3.org/TR/2009/WD-MathML3-20090924/chapter6.html#encoding-names
should it be repeated in our appendix hence in this registration then?
That does not say whether I can use these types with MathML 2.0 or not.
I would rather say that the contents of 6.2.3 should be kept together
with the registration information, and it would not hurt to elaborate a
little bit more than the proposal does at the moment. Personally I can-
not tell, for example, when I'd ever use mathml-content+xml.
Wouldn't it be wishable to reference draft-murata-kohn-lilley-xml-03
instead? Does anyone know when it'd be authoritative.
There have been proposals under that name for over five years now, it
is not very likely that consensus around proposed changed will be found
and reflected in updated drafts in the near future.
The security considerations are missing (in fact the specification
as a whole does not have a security considerations section either).
Can you suggest something?
MathML entities exchanged on the web have the same risks as any
document that could contain relative references. Is this the kind of
sentence that could be there?
MathML implementers will know better what kind of security problems
they have addressed in their implementations, so perhaps they could
contribute something to this. Yes, that would be the kind of sentence
except that it's a bit too obvious perhaps. An actual issue that may
have security implications is, for example, what if you get a MathML
document that's labeled as "content" but actually has "presentation"
markup or vice versa?
I believe the text you have under "interoperability considerations"
is misplaced there in all three cases.
misplaced like it's wrongly formulated? Formatted?
As in, it does not belong there. Interoperability considerations are
for known and anticipated interoperability problems. To take the first
entities with this media type also have the media type
application/xml and may also have the media types
application/presentation-mathml+xml or
application/content-mathml+xml.
That does not mention a problem, but makes a somewhat redundant state-
ment, and then a misleading statement about the relationship of this
type to other types (I would say both are in fact incorrect, entities
are labeled with media types, they do not intrinsically "have" them).
This is something I would expect in a discussion of the type that pre-
cedes the template information.
Under "Person & email address to contact for further information"
the proposal fails to properly separate name and email address, use
something like "Name <address>" instead.
this appears clear
If you mean that you disagree, then regardless of whether it is clear
or not, it is common practise to do so.
I do not think having a generic W3C / W3C Webmaster combination
there is a good practise.
Should there be an email? (there's one three lines above)
Should there be a group? That is easy to add.
I would be fine with a pointer to the authorship and contact infor-
mation in the specification.
--
Björn Höhrmann · mailto:bjoern(_at_)hoehrmann(_dot_)de ·
http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/