please comment on media-type registrations for MathML
derhoermi at gmx.net
Wed Oct 7 17:53:51 CEST 2009
* 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:
>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
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.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/
More information about the Ietf-types