Chris: 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]
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-mim... 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, http://www.w3.org/2002/09/ccxml Is this ok with folks? --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800