[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: A Namespace Proposal

  • From: Mike Sokolov <sokolov@ifactory.com>
  • To: Pete Cordell <petexmldev@codalogic.com>
  • Date: Mon, 13 Dec 2010 17:41:59 -0500

Re:  A Namespace Proposal

On 12/13/2010 01:01 PM, Pete Cordell wrote:
> I've been thinking about the various namespace ideas that have 
> appeared on the list, in particular Michael Kay's proposal for 
> namespaces,

Pete - I spent some time thinking about this too.  I'm with you in many 
places, but I'm not sure about the PI-based abbreviation declarations.  
I think it keeps too much of the complexity of the existing system in 
the sense that the prefix->namespace mapping is explicit, and needs to 
be tracked and managed as a kind of internal state.

An alternative I was considering is that hierarchical namespaces could 
automatically be abbreviated using any unambiguous suffix.  Basically 
you'd get a set of implicit aliases for every namespace.  As in your 
post, namespaces would be defined implicitly whenever a 
previously-undeclared prefix was introduced.

This has two very nice features.

1) Abbreviations of the namespace would no longer be arbitrary hidden 
associations (there would be no need to store separate alias->namespace 
mappings, except for prefixes brought in by old-style xmlns declarations).

2) It would be impossible to create neurotic and psychotic documents 
(using the new syntax - maintaining interoperability with XMLNS would of 
course keep this in play).

Here is an example:

<schema:bar/> <!-- same namespace -->

I had been thinking this would be context-sensitive (aliases in scope in 
descendant-or-self only), but I actually really like the idea of not 
having to re-declare your namespace later in the document.  It would 
solve the problem of interleaving namespaces, as in

<fully.qualified.namespace.xsl:template-match select="foo">

<xsl:template match="bar" />

The main thing you give up with the implicit declaration of aliases that 
there is less control over the abbreviation.  But isn't the main point 
that the abbreviation be *short*?  And after all, you can create your 
namespace to have a recognizable suffix.

Admittedly there are some pathological cases:  The dublin core namespace 
http://purl.org/dc/elements/1.1/, if inverted automagically, would 
become:  org.purl.dc.elements.1.1 (I guess?), so in theory that would 
set up an implicit alias of "1", which I guess wouldn't represent a 
valid name.  Maybe <elements.1.1:title> wouldn't be too bad.  But this 
would provide yet another reason not to include version information in a 

This sets you up for alias name clashes.  However, I spent quite a while 
looking for cases where namespace suffixes are shared and didn't find 
any.  I contrived this example, which doesn't seem to terrible:

<title>Let's make a federal case out of it</title>

<!-- in the default (gov.us.law) namespace: -->
<location>New York City</location>

<!-- AMBIGUOUS; causes an error -->

<!-- OK; these are distinguished sufficiently -->


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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.