please comment on media-type registrations for MathML
paul at activemath.org
Wed Oct 7 17:09:16 CEST 2009
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:
> 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?
> 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
I can change this.
Wouldn't it be wishable to reference draft-murata-kohn-lilley-xml-03
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1629 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20091007/a7dd9f99/attachment.bin
More information about the Ietf-types