W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2004

Re: Request for comments for Media Type registration of application/ccxml+xml

From: RJ Auburn <rj@voxeo.com>
Date: Tue, 27 Jul 2004 14:37:38 -0700
To: Chris Lilley <chris@w3.org>, Larry Masinter <LMM@acm.org>
Cc: 'Martin Duerst' <duerst@w3.org>, 'Dan Connolly' <connolly@w3.org>, Dave Raggett <dsr@w3.org>, <w3c-archive@w3.org>, <ietf-types@iana.org>, <ietf-xml-mime@imc.org>, <www-voice@w3.org>
Message-ID: <BD2C1932.161F0%rj@voxeo.com>


Comments and replies are inline. Let me know if there are any other issues:

On 07/22/2004 11:05, "Chris Lilley" <chris@w3.org> wrote:
> I agree that this sort of context, although obvious when the W3C
> document as a whole is studies, is fairly opaque when a single appendix
> is extracted and sent as an email message.
> Prepending the 'Abstract' of the specification, and giving a link to the
> full specification, would be helpful.

Sorry. I should have done this.
Martin: any chance we could update the w3c page with some examples of what
should be sent to this list? I think it might be helpful to have some
pointers to good example requests.

> When citing an RFC abcd, it is useful to do a Google search for
> "Obsoletes: abcd" and "Updates: abcd" because RFCs do not have 'latest
> version' URIs (or indeed canonical URIs at all).

Thanks for the tip...

>>> Published specification:
>>> This media type registration is for CCXML documents as
>>> described by this specification.
> 'This specification' should be a link to the main page of the document,
> even if that is a link to itself for a short document, and inline URIs
> should be indicated in the ascii text version by a numbered link [1]
> [1] http://example.org/like/this

This section now reads:

Published specification:
    This media type registration is for XML bodies that
    conform to the DTD/Schema referenced in Appendix B and C and
    interpreted by the rules of the CCXML specification [1].

      [1] http://www.w3.org/tr/ccxml/

> A conversion to text can be obtained for any W3C document by appending
> ,text to the URI (before any fragment) for example
> http://www.w3.org/TR/ccxml/,text#ccxml-mime-definition
> which is redirected to (watch out for line
> wrapping):
> http://cgi.w3.org/cgi-bin/html2txt?url=http://www.w3.org/TR/ccxml/#ccxml-mime-
> definition

Good hint. I did not know that...

> LM> I'm not 100% sure if this is necessary, but I'd expect
> LM> if the template were to appear elsewhere to see
> LM> a bibliographic citation, e.g.,
> LM> "Voice Browser Call Control: CCXML Version 1.0", W3C
> LM> Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/>
> I agree.

I will try to do that next time around...

> LM> Is "this specification" (or the whole specification) precise
> LM> enough?
> Not when the appendix is transmitted separately, no.

Once again apologies...

> LM> While this section is titled "Magic number", I think
> LM> what we're seeing in MIME registrations for XML content
> LM> is a description of how to recognize CCXML if it isn't
> LM> labeled. It would be useful here to identify the namespace
> LM> expected and the likely root XML element name(s).
> Yes, I agrre that this is current good practice. The text in this
> registration is fine, but it should add something like:
> This media type is expected to be handled by an XML processor, as
> indicated by "+xml". XML processors may detect ccXML by its namespace
> URI, http://www.w3.org/2001/vxml
> Hmm the revision to RFC 3023 should probably supply suggested
> boilerplate for this and, indeed, perhaps a registration template with
> the common items for all +xml types.

Ok, this is what it will look like now:

Magic number(s):

There is no single initial octet sequence that is always present in CCXML
documents. This media type is expected to be handled by an XML processor, as
indicated by "+xml". XML processors may detect CCXML by its namespace URI,

Is this ok with folks?

RJ Auburn
CTO, Voxeo Corporation
Received on Tuesday, 27 July 2004 17:38:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:37 UTC