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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] What's wrong with namespaces? Some observations andsuggestions

A question:

On Sat, 04 Dec 2010 23:24:22 +0000, Michael Kay wrote:
> Elements should have simple (string-valued) names, using hierarchic 
> naming to achieve uniqueness, and context-sensitive abbreviation to 
> achieve conciseness. It should always be legitimate to use the full 
> name if abbreviation is not wanted.
> Hierarchic naming: for example an element might be called 
> :org.w3c.html.table.
> Abbreviation: this might be abbreviated to "table". How is the 
> abbreviated name resolved? Using the hierarchic name of the parent 
> element. So the outermost element gives the full name
> <:org.w3c.html.html>
> and inner elements can use abbreviated names if they are in the same 
> "namespace":
> <:org.w3c.html.html>
> <head>
> <title>...</title>
> </head>
> <body>
> <:org.w3c.svg.svg>
> <rectangle>
>            ....
> Of course, this is hopelessly incompatible. Or is it?

I've been thinking about this since I first saw the post.  So I want to 
ask the question: is this incompatible?

Suppose that we go ahead and specify this, defining a 
mapping/transformation mechanism (per Michael's email) (for HTML 
only?).  Add, at the top of the document: <?name-of-spec ?>.  Existing 
parsers would have to treat this is as non-namespaced.  Anything 
wanting a Namespaces in XML-compliant version could use a standard 

In that case, this could be adopted *now* by convention, could it not?  
The parsers wouldn't choke.  Validators would, if given the base 
document; that could be handled by handing this over to an XSLT 
processor first, triggered by the presence of the processing 
instruction (but could a current XSLT processor handle names of this 
format?).  Conversely, a workflow based on this rationalized namespace 
could use absence of a processing instruction to trigger the other 
stylesheet, rewriting a Namespaces in XML-compatible instance to a 
rationalized namespaces instance.

Problem: it seems likely that current XSLT processors couldn't handle 
the transformation, as they're heavily reliant on the existing 
namespace technology, and couldn't generate or accept the rationalized 
form (due to the initial colon).  Is that true?

Problem: a standard transformation is easy for HTTP (probably the 80% 
case), but what about all those other bizarre URIs?  The urn scheme, 
for instance (which has some significant use, I know).  Can we add the 
scheme part to the transformation for those URIs and achieve 

Dimitre's just posted about some minimization, in instance documents 
and XPath.  Separating those concerns a little:

Problem: given <:org.w3c.html.html>, is the proper match 
</:org.w3c.html.html>, or </html>, or either?

Problem: in XPath, can we follow the pattern of the instance for 
abbreviation?  Thus: /:org.w3c.html.html/body/p ?  In context, that's 
more or less (well, more less than more, given nesting of p elements in 
other things, but play along, 'kay?) equivalent to //:org.w3c.html.p 
... or could we say //p ?

Amelia A. Lewis                    amyzing {at} talsever.com
But pain ... seems to me an insufficient reason not to embrace life.  
Being dead is quite painless.  Pain, like time, is going to come on 
regardless.  Question is, what glorious moments can you win from life 
in addition to the pain?
   -- Cordelia Naismith Vorkosigan [Lois McMasters Bujold, "Barrayar"]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS