- From: Ian Graham <igraham@ic-unix.ic.utoronto.ca>
- Date: Wed, 20 Feb 2002 21:59:07 -0500 (EST)
- To: "Simon St.Laurent" <simonstl@simonstl.com>
- cc: Mark Nottingham <mnot@mnot.net>, www-tag@w3.org, ietf-xml-mime@imc.org
I concur with Simon here. As has been noted before, the root namespace is often not the one you want to 'dispatch' based on. I think it makes more sense to think of the namespace 'set' specified in a MIME header as representing a 'processing signature hint' for the data. But note that this hint is not unique for a document -- it can vary depending on how you want the data to be processed. Looked at this way, the root namespace is no longer that important -- it's just one potential namespace part of the overall signature. Hope this makes sense -- Ian On 19 Feb 2002, Simon St.Laurent wrote: > > On Tue, 2002-02-19 at 19:20, Mark Nottingham wrote: > > Might I suggest that any revision of RFC3023 include a new parameter > > for application/xml and text/xml (say, 'rootNS') that contains the > > root element's namespace URI, to allow HTTP content negotiation with > > current implementations? Yes, this won't address cases where there is > > a need to negotiate on more than one namespace in the document, but > > it will certainly help with the simple cases, where dispatch is based > > upon the root element's namespace (which seems to be the direction > > things are going in). > > You're welcome to register a rootNS content feature. > > I have to admit that I don't understand or sympathize with the > fascination with root element namespaces, and don't believe that RFC > 3023 needs to add any XML-specific parameters, but a content feature > should take care of what you're looking for. > > -- > Simon St.Laurent > Ring around the content, a pocket full of brackets > Errors, errors, all fall down! > http://simonstl.com > >
Received on Wednesday, 20 February 2002 22:09:06 UTC