On Wed, Jul 13, 2005 at 12:33:04PM -0400, Gerald McCobb wrote:

1. In particular there is the work in the W3C Compound Document Format (CDF) working group. They are looking at defining a single media type that will handle the many possible document format combinations of XHTML, SVG, Voice, SMIL, XForms, etc. This media type may include multiple "+" put in a profile attribute.

As a member of that WG, I can state (though not speaking for it) that I've not seen this proposed, though it's possible it was mentioned in passing. You might be interested to know that of all the possible media type names that have been suggested, all use "-" instead of "+" in the subtype name preceding the "+xml" suffix. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com

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

* Bjoern Hoehrmann wrote:

* Gerald McCobb wrote:

...

I asked the IESG to postpone the publication of the application/xhtml-voice+xml media type as an informational RFC. The registration is not correct. It should be application/xhtml+voice+xml. The application/xhtml+voice+xml media type was the original submission.

As I pointed out earlier, I do not really see a good reason to add this http://eikenes.alvestrand.no/pipermail/ietf-types/2005-March/000662.html type. http://www.ietf.org/rfc/rfc3236.txt notes the possibility of using application/xhtml+xml for XHTML M12N-based formats.

http://www.voicexml.org/specs/multimodal/x+v/12/ also takes steps to increase the likelyhood that XHTML+Voice documents degrade in down-level clients that just support application/xhtml+xml, so indeed, as noted in the Internet-Draft, the type would be of limited use.

I'm not sure what you mean by "degrade." It is true that XHTML+Voice follows the XHTML 1.1 modularization standard and the XML-Events, VoiceXML, and X+V markup is isolated from the XHTML by their respective namespaces. An XHTML+Voice application running successfully as an XHTML-only application has been thoroughly tested on MS Internet Explorer and Mozilla Firefox browsers. However, as noted in the Internet-Draft, XHTML+Voice user agents have special processing requirements including support for XML Events and VoiceXML. An initialized VoiceXML interpreter is a specific requirement. This mime type is limited to XHTML+Voice applications and I don't propose to change the limited designation in the internet draft.

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt notes 'While it is possible for a given media type to be assigned additional names, the use of different names to identify the same media type is discouraged'.

This mime type is for user agents that support the specific processing requirements of XHTML+Voice applications.

...

One of the reviewers pointed out that "a certain class of error could be

...

avoided by renaming this application/xhtml-plus-voice+xml... I don't know of any other "+xml" [see RFC3023] media types that have a "+" in the name... a poorly-constructed regexp looking for +xml along the lines of /\+(.*)$/ would miss this one."

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt notes 'More generally, use of "+suffix" constructs should be done with care given the possibility of conflicts with future suffix definitions'.

Are "+suffix" constructs the same as putting "+" within the subtype? A mime type such as application/xhtml+voice+xml that maps directly to XHTML+Voice is easy for authors to understand. I still see the "-" as minus. What does application/xhtml-voice+xml mean but XHTML minus voice. As you know, XHTML already doesn't have voice... Regards, Gerald McCobb IBM 8051 Congress Avenue Boca Raton, FL 33487 Tel. # 561-862-2109 T/L 975-2109 Bjoern Hoehrmann <derhoermi@gmx.net> 07/14/2005 10:21 AM To: Gerald McCobb/Boca Raton/IBM@IBMUS cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: Registration of media type application/xhtml-voice+xml * Gerald McCobb wrote:

I asked the IESG to postpone the publication of the application/xhtml-voice+xml media type as an informational RFC. The registration is not correct. It should be application/xhtml+voice+xml. The application/xhtml+voice+xml media type was the original submission.

As I pointed out earlier, I do not really see a good reason to add this http://eikenes.alvestrand.no/pipermail/ietf-types/2005-March/000662.html type. http://www.ietf.org/rfc/rfc3236.txt notes the possibility of using application/xhtml+xml for XHTML M12N-based formats. http://www.voicexml.org/specs/multimodal/x+v/12/ also takes steps to increase the likelyhood that XHTML+Voice documents degrade in down-level clients that just support application/xhtml+xml, so indeed, as noted in the Internet-Draft, the type would be of limited use. http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt notes 'While it is possible for a given media type to be assigned additional names, the use of different names to identify the same media type is discouraged'.

One of the reviewers pointed out that "a certain class of error could be avoided by renaming this application/xhtml-plus-voice+xml... I don't know

of any other "+xml" [see RFC3023] media types that have a "+" in the name... a poorly-constructed regexp looking for +xml along the lines of /\+(.*)$/ would miss this one."

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt notes 'More generally, use of "+suffix" constructs should be done with care given the possibility of conflicts with future suffix definitions'. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

* Bjoern Hoehrmann wrote:

* Gerald McCobb wrote:

...

However, as noted in the Internet-Draft, XHTML+Voice user agents have special processing requirements including support for XML Events and VoiceXML. An initialized VoiceXML interpreter is a specific requirement. This mime type is limited to XHTML+Voice applications and I don't propose to change the limited designation in the internet draft.

Much of the existing application/xhtml+xml content relies on support of a variety of features such as the Macromedia Flash format and scripting. I think the litmus test here is simple: are user agents that do not support XHTML+Voice but XHTML 1.0/1.1 required to reject application/ xhtml-voice+xml content as beeing in an unsupported format?

XHTML+Voice adds the voice mode of interaction to web applications. This additional mode of interaction is not that important for desktop clients. Voice Interaction is useful for clients with limited processing, memory, and network resources, such as cell phones and wireless PDAs. For clients that don't accept XHTML+Voice markup it matters whether it has to receive and ignore additional markup. For these clients it is important that applications send markup dedicated to what they support.

If yes, a new media type is certainly justified. If it is acceptable or even encouraged to process the content by ignoring the unknown bits then there does not seem to be considerable value in this new type. As you pointed out, W3C might at some point produce a recommendation where you can use XHTML with inline SVG content; with application/xhtml-voice+xml it's not really clear whether XHTML+Voice+SVG content should use application/xhtml+xml, application/xhtml-voice+xml, or some third type.

XHTML+Voice adds voice as another mode of interaction with the application, while SVG is in most cases an important informational part of the application.

XHTML+SVG content, unless the SVG fragments are in the <head> element and referenced via something like <object data="#svg" />, would depend even more on inline-SVG support than XHTML+Voice on inline VoiceXML support, if we need to define a new media type for each combination of XML formats, we'll quickly get a system where it simply does not matter whether one uses specialized types or just application/xml.

This is one of the issues before the W3C CDF working group.

...

Are "+suffix" constructs the same as putting "+" within the subtype? A mime type such as application/xhtml+voice+xml that maps directly to XHTML+Voice is easy for authors to understand. I still see the "-" as minus. What does application/xhtml-voice+xml mean but XHTML minus voice. As you know, XHTML already doesn't have voice...

And application/xml-dtd is for XML documents without DTD? Registered types with "-" typically use the "-" to separate words. As you pointed out, there aren't really types for "compound" formats yet; but it is also not clear to me whether we should have such types at all. If the CDF Working Group is really considering to have a single type for a very wide range of combinations, why can't you use that type instead?

I'm talking about a perception that leads to a misunderstanding that I have already received. I understand that application/xml-dtd means "xml dtd" but "application/xhtml-voice" means "xhtml voice" and the language is "xhtml+voice". We don't know today what the CDF working group will decide and their decision is probably a few years away. In the meantime, there are XHTML+Voice applications in operation today. Regards, Gerald McCobb IBM 8051 Congress Avenue Boca Raton, FL 33487 Tel. # 561-862-2109 T/L 975-2109

On Tue, 02 Aug 2005 10:14:02 +0200, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

Well, application/xhtml+xml has a profile parameter to indicate specific profiles such as XHTML+Voice; why is a new XHTML+Voice media type preferable here?

This is only semi-related to this question, but profile parameters are unreliable. OMA did something similar with a Mobile Profile of XHTML (an almost pure subset of XHTML), using the XHTML content type. As a consequence we tested parameters and found them somewhat unreliable. I don't remember the details but clients didn't always lop the parameters off, servers didn't always serve them. I guess this just goes to show that if a feature is unused long enough interoperability suffers (that it is unused may also indicate that this wasn't such a good idea but that is another debate). -- Jonny Axelsson, Core Technology, Opera Software ASA

Bjoern Hoehrmann wrote:

* Gerald McCobb wrote:

...

1. In particular there is the work in the W3C Compound Document Format (CDF) working group. They are looking at defining a single media type that will handle the many possible document format combinations of XHTML, SVG, Voice, SMIL, XForms, etc. This media type may include multiple "+"

...

put in a profile attribute.

From http://w3.org/2004/CDF/admin/charter and http://w3.org/TR/CDRReqs/ it rather seems they are currently working on the first draft on using XHTML 1.x where the user agent supports some version of SVG through the XHTML object element. The media type for XHTML 1.x is application/ xhtml+xml, I seriously doubt they are going to propose new media types for something that had a media type for many years now and has in fact been implemented for quite some time. It would cause a lot of confusion for no good reason.

Other than that, it is quite obvious that use of media type parameters or deploying new media types for XML-over-HTTP content is difficult, to say the least. It's difficult to see how new types or type+parameter combinations might work with running code or which infrastructural changes are supposed to support this; or what we might gain from it.

Clearly though, if the CDF Working Group is working on architectural solutions here they should publish their current thinking as Internet- Draft.

I'm not a member of the CDF Working group but I believe they plan to do more than standardizing referencing SVG from the XHTML object tag.

From http://w3.org/TR/CDRReqs/ there is also document compounding by inclusion. XHTML+Voice is an informative example.

Regards, Gerald McCobb IBM 8051 Congress Avenue Boca Raton, FL 33487 Tel. # 561-862-2109 T/L 975-2109