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: <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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format