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

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:

<org.example.schema:foo>
<schema:bar/> <!-- same namespace -->
</org.example.schema:foo>


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>

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


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:

<gov.nyc.law.case>
<title>Let's make a federal case out of it</title>
<gov.us.law.jurisdiction>

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

<!-- AMBIGUOUS; causes an error -->
<law.case-number>123</case-number>

<!-- OK; these are distinguished sufficiently -->
<nyc.law.case-number>123</case-number>
<us.law.case-number>123</case-number>

</jurisdiction>
</case>

• Follow-Ups:
  • Re: A Namespace Proposal
    • From: "Pete Cordell" <petexmldev@c...>

• References:
  • A Namespace Proposal
    • From: "Pete Cordell" <petexmldev@c...>