thank you Bjoern,
Le 07-oct.-09 à 16:14, Bjoern Hoehrmann a écrit :
In this specification draft, one can find three registrations for
media-types related to MathML in the appendix B:
http://www.w3.org/TR/2009/WD-MathML3-20090924/appendixb.html
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?
As per RFC 3023, the charset definition and encoding considerations
should be referenced as follows, which the proposals fails to do:
Registrations for new XML-based media types under top-level types
other than "text" SHOULD, in specifying the charset parameter and
encoding considerations, define them as: "Same as [charset parameter
/ encoding considerations] of application/xml as specified in RFC
3023."
I can change this.
Wouldn't it be wishable to reference draft-murata-kohn-lilley-xml-03
instead?
Does anyone know when it'd be authoritative.
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?
I believe the text you have under "interoperability considerations"
is misplaced there in all three cases.
misplaced like it's wrongly formulated? Formatted?
I note that under "Applications that use this media type" you have
"(todo)". Going to Last Call with "todo" markers left is not a good
practise. I note that the purpose of this field is to give a general
idea of what kind of applications use it, not to list individual
software products.
thanks, will do.
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
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.
paul
smime.p7s
Description: S/MIME cryptographic signature