Re: please comment on media-type registrations for MathML

Paul Libbrecht <> Tue, 24 November 2009 16:04 UTC

Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id nAOG40OO094376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 09:04:00 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id nAOG40qG094375; Tue, 24 Nov 2009 09:04:00 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with ESMTP id nAOG3mwx094354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Tue, 24 Nov 2009 09:03:59 -0700 (MST) (envelope-from
Received: from (localhost []) by imss.7 (Postfix) with ESMTP id B7D9C31743; Tue, 24 Nov 2009 17:03:46 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id A4E2331737; Tue, 24 Nov 2009 17:03:46 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 306D131165; Tue, 24 Nov 2009 17:03:46 +0100 (CET)
From: Paul Libbrecht <>
To: Paul Libbrecht <>
Subject: Re: please comment on media-type registrations for MathML
References: <D1EFB337111B674B8F1BE155B01C6DD6034CCA68@franklin.corp.dessci>
Message-Id: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 24 Nov 2009 17:02:56 +0100
X-Mailer: Apple Mail (2.936)
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

Dear media-types-expert,
Dear Björn,

> Forwarded-from :
> From : "Robert Miner" <>
> Date : 24 novembre 2009 03:43:50 GMT+01:00
> To : <>
> Archived-At: < 
> >
> 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
> 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
> 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