OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] nested namespaces

[ Lists Home | Date Index | Thread Index ]

Mark Baker writes:
>On Sun, Dec 15, 2002 at 05:23:07PM -0500, Simon St.Laurent wrote:
>> Any thoughts?  I don't see any obvious answers here.
>
>I put a lot of thought into this a while ago, and started an Internet
>Draft on it[1].  It needs more work, but more importantly, needs to be
>addressing a problem that enough people are having.
>
> [1] 
>http://www.markbaker.ca/2002/01/draft-baker-generic-xmlns-dispatch-00.
>txt

I'm not entirely sure from reading the draft what it is that you're
proposing or that a media type (as opposed to a media feature[1], for
instance) is the right way to go about it.  My summary of the document
would suggest that content of type application/xmld should be processed
on a namespace-URIs-first basis, but it's not clear to me what
(especially in the absence of a schema or perhaps better a RDDL
document) should be done when unknown namespaces are encountered.

I think that document is an interesting start, but it's not clear to me
that "dispatch" is the right paradigm for namespace-based processing. 
Dispatch makes sense in the context of, say, an XHTML document with
embedded XForms and SVG and using plug-in-like mechanisms for the
handling.  I'm not sure it makes the same kind of sense as a general
approach to handling namespaces and XML - but I'll confess that I'm not
sure what a general approach might look like.

All that Namespaces in XML really says about such matters is "An XML
namespace is a collection of names, identified by a URI reference
[RFC2396], which are used in XML documents as element types and
attribute names."

There are a few untypical cases worth considering.  One that I
initially thought was perverse but which I keep hearing about on a more
regular basis is the case where the local name is treated as primary
and the namespace URI is considered metadata - disambiguating names,
certainly, but not in a simple URI<->vocabulary kind of way.

The most obvious (and perhaps laughable) case is the use of namespaces
for data types. Last year at XML 2001 I talked with John Cowan about an
idea I had for Perversely Oriented Namespace Datatyping (POND), but I
haven't gotten around to implementing it. Roughly, the idea looks kind
of like:

<record xmlns="http://simonstl.com/ns/record";
         xmlns:str="http://www.w3.org/TR/xmlschema-2/#string";
         xmlns:date="http://www.w3.org/TR/xmlschema-2/#date";
         xmlns:int="http://www.w3.org/TR/xmlschema-2/#int";
         >
   <str:firstName>Simon</str:firstName>
   <date:birthdate>1970-11-25</date:birthdate>
   <int:age>32</int:age>
</record>

In this case, the "collection of names" is a collection of names that
happen to contain strings, dates, or integers, not a collection that
was precisely connected to a vocabulary.

Also, local names have real power - href and id are two very common
local names used in multiple namespaces, for instance. (You acknowledge
that in the draft.)  There are real cases where that local name may in
fact be more important to processing (link and bastardized ID hunting)
than the namespace that happens to be applied to it.  This kind of
thing keeps coming up in various contexts, and I doubt it will
disappear soon.

I wish I saw a simple 80/20 here, but I really don't, especially if
elements using unknown "visiting" namespaces contain content in "known"
namespaces.

[1] - http://simonstl.com/ietf/draft-stlaurent-feature-xmlns-03.txt is a
media feature which identifies the namespaces used in a document rather
than specifying their processing, but a media feature saying something
like "this document expects namespace dispatching" might make sense and
be easily integrated with a wide variety of +xml types.


-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS