Chris Lilly wrote:
CL> GM> I asked the IESG to postpone the publication of the
GM> application/xhtml-voice+xml media type as an informational RFC. The
CL> GM> registration is not correct. It should be
GM> application/xhtml+voice+xml. The application/xhtml+voice+xml media
CL> GM> type was the original submission.
CL> The entire reason that the +xml suffix was changed from the original
CL> -xml suffix was beczause there were a number of hyphenated types in
CL> use but little/no types where the terms were separated by +.
The application/xhtml+voice+xml media was chosen because it directly
maps to "XHTML+Voice", the name of the language, and is thus an easy
mnemonic help for authors - whereas I might imagine people getting
confused by XHTML+Voice using the application/xhtml-voice+xml or
application/xhtml-plus-voice+xml type.
CL> GM> There is an issue with the original submission:
CL> GM> One of the reviewers pointed out that "a certain class of error
CL> GM> could be avoided by renaming this
CL> GM> application/xhtml-plus-voice+xml... I don't know of any other
CL> GM> "+xml" [see RFC3023] media types that have a "+" in the name...
CL> GM> a poorly-constructed regexp looking for +xml along the lines of
CL> GM> /\+(.*)$/ would miss this one."
CL> I agree that so far there are no types with a + in the name, and
CL> that using some other allowed separator would be preferable.
As far as I know, XHTML+Voice is the first example of a compound document
format requesting registration of a media type. There has not been
a reason before to have a type with a "+" in the name. The fact that
"+" has not been used before is not a reason to exclude using it for the
first time.
CL> GM> 1. In particular there is the work in the W3C Compound Document
CL> GM> Format (CDF) working group. They are looking at defining a
CL> GM> single media type that will handle the many possible document
CL> GM> format combinations of XHTML, SVG, Voice, SMIL, XForms, etc.
CL> GM> This media type may include multiple "+" put in a profile
CL> GM> attribute.
CL> Probably not (I for one would argue against it, being a member of
CL> that group). But 'may include' is pretty weak.
Regardless of what the CDF working group will eventually decide this
XHTML+Voice media type registration could set a precedent for all
formats that add language subsets to container languages (such as XHTML).
I'm not comfortable with setting a precedent for "xhtml-plus-svg-plus-
smil-plus-xforms", for example.
CL> GM> 2. The argument for having "+" in the subtype is unconvincing,
CL> GM> given that the simplest method to determine if something is XML
CL> GM> is also the safest, that is, if the last four characters are
CL> GM> "+xml" or "/xml" then the document is XML, otherwise it is not.
CL> GM> If that has to be done with regexps, instead of just examining
CL> GM> the last four bytes, that would be /[/+]xml$/. If type and
CL> GM> subtype were split already it would be /\+?xml$/ for the
CL> GM> subtype.
CL> True.
Then we agreed that "poorly written regexps" is not a good reason for
excluding use of "+" in the type?
Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109