W3C home > Mailing lists > Public > www-tag@w3.org > February 2002

Re: Revised Internet-Draft: Media Feature - xmlns

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
Message-ID: <Pine.SOL.4.21.0202201851170.24607-100000@ic-unix.ic.utoronto.ca>

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 --


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:49 UTC