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

Re: Namespaces, bad idea or worst idea? (Was xpath que

Subject: Re: Namespaces, bad idea or worst idea? (Was xpath query failing)
From: "Eliot Kimber ekimber@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 23 Apr 2016 16:50:09 -0000
Re:  Namespaces
Upon reflection I can see that allowing unprefixed elements to be
associated with a namespace was perhaps not the best idea, although it is
consistent with the general idea of a namespace being a property of an

I believe I had left the W3C and the XML Working Group by time the final
details of namespaces were nailed down so I can't claim to have supported
or objected to the final design.

I always objected to the lack of a formal way to bind a namespace to a set
of names. People seemed to assume that knowing the namespace meant you
knew the set of allowed names in that namespace, but of course there is
nothing in any W3C-defined specification that does that. The best we have
is "some namespaces may be associated with specifications that define the
set of names in the namespace". Otherwise the namespace name is just a
magic string that serves to make element type names universally unique.

And as somebody pointed out to me privately, the fact that there was no
good solution for DTD-based grammars was a problem too. But I think we all
expected DTDs to go away much faster than they did.

I will observe that the DITA specification cannot use namespaces except
for foreign elements (meaning elements that are explicitly not DITA-based
elements) and will probably never be able to use namespaces because of the
complexity having to provide namespace mappings in DITA's class mechanism
would entail. Our solution is to simply use prefixes on local names to
make it less likely they'll conflict with other element types, e.g., the
"lc" used on all the Learning and Training elements (lcInteraction,
lcAssessment, etc.). It's as good as a conventional namespace prefix with
none of the pain of real namespaces.

The one place DITA does use (and depend on) namespaces is to have one
required attribute on root elements that is in a DITA-defined namespace.
This attribute serves to make DITA documents self-describing as being DITA
documents. Coupled with the @domains and @class attributes, which define
the set of vocabulary modules used and the mapping to the standard-defined
base types respectively, all conforming DITA documents carry with them
sufficient information to be both reliably identified as DITA and to know
what their grammar rules are (because the all DITA elements must conform
to the constraints defined by the base elements they must map to). This
identifiability is irrespective of the markup details in the
instance--because DITA allows controlled definition of new vocabulary
based on existing vocabulary the element type names themselves are not
useful for determining if a document is or is not a DITA document.



Eliot Kimber, Owner
Contrext, LLC

On 4/22/16, 5:31 PM, "Michael Kay mike@xxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>> On 22 Apr 2016, at 21:58, Eliot Kimber ekimber@xxxxxxxxxxxx
>><xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> It seemed like a good idea at the time ....
>Not to me it didn't.
>Sadly, I can't track down the post where I recall saying that it didn't
>matter that the design of namespaces was horrible, because it was so bad
>that no-one would ever use them.
>Michael Kay

Current Thread


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