[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
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 element. 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. Cheers, E. ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com 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 >Saxonica
|
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
|