- From: Paul Libbrecht <paul@activemath.org>
- Date: Tue, 24 Nov 2009 17:02:56 +0100
- To: Paul Libbrecht <paul@activemath.org>
Dear media-types-expert, Dear Björn, > Forwarded-from : member-math@w3.org > From : "Robert Miner" <robertm@dessci.com> > Date : 24 novembre 2009 03:43:50 GMT+01:00 > To : <member-math@w3.org> > Archived-At: <http://www.w3.org/mid/D1EFB337111B674B8F1BE155B01C6DD6034CCA68@franklin.corp.dessci > > > > Dear Björn, > > I am writing in response to your comments on the media-type > registrations for MathML given in Appendix B of the Last Call draft of > the MathML 3 Specification. Your original comments are recorded at > http://www.alvestrand.no/pipermail/ietf-types/2009-October/ > 002268.html. > > We have modified Appendix B, and believe we have addressed the issues > you noted. The changes are explained below, and you can see the draft > changes in an editor's draft of the spec located at > > http://monet.nag.co.uk/~dpc/draft-spec/appendixb.html > > Since we need to record the resolution of all Last Call comments, > could we ask you to let us know whether you accept these changes as > addressing your comments? Thanks in advance. > > The specific actions taken are: > > > 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. > > A new introductory section entitled "Selection of Media Types for > MathML Instances" was added to specifically address this issue. The > related text in section 6.2.3 of the spec is essentially summary in > nature, and was therefore left unchanged. It already referred to > appendix B for detailed information on the usage of the media types, > and that information is now given. > > The section carefully defines the presentation and content MathML > vocabularies, and gives a clear rule for determining what media type > should be used for a given MathML instance based on the contents of > that instance. > > The section also contains some explanation and examples to motivate > the usage of the three MathML media types. The section ends by > addressing use of the media types with earlier versions of MathML > > > 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." > > These sections have been edited to match the proper format. > > > The security considerations are missing (in fact the specification > > as a whole does not have a security considerations section either). > > Security considerations have been added. We have listed both the > generic issues common to similar XML languages, and two issues > specific to MathML: the possible presence of executable code in > semantic annotations, and the (possibly inadvertant) denial of service > risks arising in computational contexts from trying to solve > unsolvable problems. > > > I believe the text you have under "interoperability considerations" > > is misplaced there in all three cases. > > This text has been completely rewritten. Again, there are some > generic considerations common to similar XML languages, as well as > several MathML specific issues. In particular, lack of versioning > information in MathML instances introduces a backward compatibility > concern, and the result of evaluating MathML expressions is not > guaranteed to be the same in different computational systems. > > > 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. > > Thank you for the clarification on the purpose. We have filled out > the section appropriately. > > > 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. I do not think having a > > generic W3C / W3C Webmaster combination there is a good practise > > Following other media type registrations under the BCP13 process, we > have changed this to list Paul as the person, with the Math WG group > mailing list for the address, followed by a pointer to the public W3C > Math web site for additional information. > > --Robert > >
Received on Tuesday, 24 November 2009 16:04:23 UTC