Re: please comment on media-type registrations for MathML

Bjoern Hoehrmann <> Wed, 07 October 2009 15:53 UTC

Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id n97Frl36006258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2009 08:53:47 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id n97FrljX006257; Wed, 7 Oct 2009 08:53:47 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with SMTP id n97FrjeK006250 for <>; Wed, 7 Oct 2009 08:53:46 -0700 (MST) (envelope-from
Received: (qmail invoked by alias); 07 Oct 2009 15:53:44 -0000
Received: from (EHLO hive) [] by (mp001) with SMTP; 07 Oct 2009 17:53:44 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19r/SUOBzVreU5RagD0lDMKyiJnwsRc0KpVO5cIag GEPGptypbEB4L5
From: Bjoern Hoehrmann <>
To: Paul Libbrecht <>
Cc:,, Math Working Group WG <>
Subject: Re: please comment on media-type registrations for MathML
Date: Wed, 07 Oct 2009 17:53:51 +0200
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.61
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

* 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
  application/presentation-mathml+xml or

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 · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·