Contents

• Summary
• Specification Publication Milestones
• Principal References
• General References: Articles, Papers, News, Blogs

Summary

The purpose of an XML namespace is to allow the deployment of XML vocabularies (in which element and attribute names are defined) in a global environment and to reduce the risk of name collisions in a given document when vocabularies are combined. For example, the MathML and SVG specifications both define the set element. Although XML data from different formats such as MathML and SVG can be combined in a single document, in this case there could be ambiguity about which set element was intended. XML namespaces reduce the risk of name collisions by taking advantage of existing systems for allocating globally scoped names: the URI system. When using XML namespaces, each local name in an XML vocabulary is paired with a URI (called the namespace URI) to distinguish the local name from local names in other vocabularies. The use of URIs confers additional benefits. First, each URI/local name pair can be mapped to another URI, grounding the terms of the vocabulary in the Web. These terms may be important resources and thus it is appropriate to be able to associate URIs with them... Another benefit of using URIs to build XML namespaces is that the namespace URI can be used to identify an information resource that contains useful information, machine-usable and/or human-usable, about terms in the namespace. This type of information resource is called a namespace document. When a namespace URI owner provides a namespace document, it is authoritative for the namespace..." ["XML namespaces", Architecture of the World Wide Web, Volume One ]

"We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a "markup vocabulary") that are defined for and used by multiple software modules. One motivation for this is modularity: if such a markup vocabulary exists which is well-understood and for which there is useful software available, it is better to re-use this markup rather than re-invent it. Such documents, containing multiple markup vocabularies, pose problems of recognition and collision. Software modules need to be able to recognize the elements and attributes which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element name or attribute name. These considerations require that document constructs should have names constructed so as to avoid clashes between names from different markup vocabularies. This specification describes a mechanism, XML namespaces, which accomplishes this by assigning expanded names to elements and attributes..." [Namespaces in XML 1.1]

"Namespaces, originally designed to provide names for XML elements and attributes, have been adopted much more broadly by the web community. They are now used not simply for elements and attributes but for function names, tokens, and identifiers for ever more purposes..." [The Disposition of Names in an XML Namespace]

The names in a namespace form a collection:

• sometimes it is a collection of element names (DocBook and XHTML, for example)
• sometimes it is a collection of attribute names (XLink, for example)
• sometimes it is a collection of functions (XQuery 1.0 and XPath 2.0 Data Model)
• sometimes it is a collection of properties (FOAF)
• sometimes it is a collection of concepts (WordNet), and many other uses are likely to arise.

There's no requirement that the names in a namespace only identify items of a single type; elements and attributes can both come from the same namespace as could functions and concepts or any other homogeneous or heterogeneous collection you can imagine. The names in a namespace can, in theory at least, be defined to identify any thing or any number of things..." [Associating Resources with Namespaces]

Specification Publication Milestones

[August 06, 2009] "W3C Proposed Edited Recommendation: Namespaces in XML 1.0 (Third Edition)." By Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin (et al), W3C Technical Report. Members of the W3C XML Core Working Group published the Third Edition of Namespaces in XML 1.0 as W3C Proposed Edited Recommendation. "XML Namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references. The Third Edition as proposed incorporates all outstanding errata." A colored diff-marked version highlights the changes (added text, changed text, deleted text). The review period is open until 14-September-2009. "There are several editorial changes, including a number of terminology changes and additions intended to produce greater consistency. The non-normative appendix "The Internal Structure of XML Namespaces" has been removed. The BNF has been adjusted to inter-connect properly with all editions of XML 1.0, including the fifth edition."

[August 16, 2006] Namespaces in XML 1.0 (Second Edition) . W3C Recommendation. 16-August-2006. Edited by Tim Bray (Textuality), Dave Hollander (Contivo, Inc.), Andrew Layman (Microsoft), Richard Tobin (University of Edinburgh and Markup Technology Ltd). See also Namespaces in XML 1.1 Requirements . With errata page and public archives for 'xml-names-editor@w3.org' list.

[February 2004] Namespaces in XML 1.1 . W3C Recommendation. 4-February-2004. Edited by Tim Bray (Textuality), Dave Hollander (Contivo, Inc), Andrew Layman (Microsoft), and Richard Tobin (University of Edinburgh and Markup Technology Ltd). See the news story "Extensible Markup Language (XML) Version 1.1 Published as a W3C Recommendation."

[April 11, 2002] W3C XML Core Working Group Publishes New Working Drafts for Namespaces in XML. The XML Core Working Group has produced two new working draft specifications on namespaces as part of the W3C XML Activity. Namespaces in XML 1.1 is the "first draft of a new 1.1 revision of the Namespaces in XML specification which will incorporate several errata to the 1.0 specification, and will make one substantive change: the provision of a mechanism to undeclare prefixes." Namespaces in XML 1.1 Requirements presents the requirements for the development of Namespaces in XML version 1.1. XML namespaces "provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references." The Requirements document clarifies that the Namespaces in XML 1.1 specification will apply only to XML version 1.1 documents; note that some examples in the WD mistakenly use version 1.0 identifier (<?xml version="1.0"?>) where "1.1" is intended. According to the WG's explanation, the Namespaces in XML 1.0 "has the ability to undeclare the default namespace, but doesn't provide a facility to undeclare namespaces with prefixes; an obvious syntax for such functionality would be an empty namespace attribute value (xmlns:prefix=""); this omission has had adverse consequences on infoset manipulations and serializers." Other specifications negatively affected by the V1.0 limitation include XML-Signature Syntax and Processing, SOAP Version 1.2 part 1: Messaging Framework, XML Inclusions (XInclude) 1.0, XQuery 1.0, and XPath 2.0 and XQuery 1.0 Data Model. [Full context]

[January 14, 1999] On January 14, 1999, the World Wide Web Consortium issued a press release announcing the publication of "Namespaces in XML" as a W3C Recommendation. References: REC-xml-names-19990114, World Wide Web Consortium 14-January-1999. The document editors include Tim Bray (Textuality), Dave Hollander (Hewlett-Packard Company), and Andrew Layman (Microsoft). XML namespaces "provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references. An XML namespace is a collection of names, identified by a URI reference (RFC2396), which are used in XML documents as element types and attribute names. The 'Namespaces in XML' specification resolves potential name clashes by using the Web addressing infrastructure. The new specification allows authors to mix two or more XML-based languages in one document without conflict or ambiguity, thus promoting the modular development and reuse of XML languages and applications. The modularity and simplicity of XML technology combined with namespaces paves the way for future developments, such as the work in progress in W3C's XML Schema Working Group, and data exchange based on W3C's Resource Description Framework (RDF) architecture."

[July 10, 1999] W3C Proposal for CSS Namespace Enhancements. The W3C has published a working draft document on CSS Namespace Enhancements which constitutes one document in a modular set of Working Drafts which will define the next level of CSS (Cascading Style Sheets). Reference: W3C Working Draft 25-June-1999; the editor is Peter Linss of Netscape Communications. The WD offers a "proposal for making CSS namespace-aware, such that styles can be applied to XML documents which use multiple namespaces, correctly selecting by the namespace used, regardless of the namespace prefix which happens to be used. The goal is to provide the ability for CSS selectors to operate effectively against XML documents that make use of XML namespaces. This document defines a new at-rule, additional selector modifiers, and a modification to the attr() value for the 'content' property. The following user/author needs are addressed: (1) Ability to specify type selectors that apply to element types within a given namespace. (2) Ability to specify attribute selectors that apply to attributes within a given namespace. (3) Ability to address attributes within a given namespace with the attr() function." And the rationale: "In XML namespaces, a namespace is identified solely by a URI reference. A prefix mechanism is defined to bind namespace URIs to XML names forming qualified names. Since namespace prefixes are defined within the XML document, and furthermore only apply to a limited scope within the document, the prefixes are not suitable for use outside the XML markup. Since a style sheet author can not, in general, know a priori which prefixes an XML author will map to a particular namespace, or to which namespace a particular prefix is bound in any given context, the stylesheet author must have some mechanism to identify namespaces by their URI." For CSS references, see "W3C Cascading Style Sheets".

[September 16, 1998] A W3C Working Draft "Namespaces in XML" was published on September 16, 1998. References: WD-xml-names-19980916, World Wide Web Consortium Working Draft 16-September-1998. The editors are Tim Bray (Textuality), Dave Hollander (Hewlett-Packard Company), and Andrew Layman (Microsoft). With the publication of this working draft, the Namespace specification entered its 'last call' for comments.

[August 03, 1998] The W3C released a new working draft of "Namespaces in XML." References: WD-xml-names-19980802, World Wide Web Consortium Working Draft 2-August-1998. Its editors are Tim Bray (Textuality), Dave Hollander (Hewlett-Packard Company), and Andrew Layman (Microsoft). The working draft is available in HTML and XML format. Abstract: "XML namespaces provide a simple method for qualifying names used in Extensible Markup Language documents by associating them with namespaces identified by URI." Document status: "This draft embodies a large-scale revision of the namespace specification. While it is unfinished in some respects, the Working Group intends to keep the features it describes functionally unchanged unless problems are discovered during early implementation work. To discover such problems as quickly as possible, a special editorial team has been formed to receive feedback from implementors during a one-month period beginning with the publication of the working draft and ending shortly after the XML Working Group meeting in Montreal August 22-23. Please send implementation experience reports to xml-names-issues@w3.org." Jon Bosak (W3C XML WG Chair) posted a related announcement; James Clark posted a recipe for implementation in Java ("it is really easy to implement").

[May 26, 1998] The World Wide Web Consortium (W3C) released a new version of the document "Namespaces in XML" as a Working Draft. References: WD-xml-names-19980518, World Wide Web Consortium Working Draft 18-May-1998. The authors are: Tim Bray (Textuality), Dave Hollander (Hewlett-Packard Company), and Andrew Layman (Microsoft). The XML Working Group expects that the namespace facility will "become an integral part of some future version of the XML specification." The XML namespaces design has two principal motivations for allowing XML names (e.g., element type names and attribute names) to be qualified by a domain or schema name: (1) the desire to provide a mechanism for distinguishing between multiple DTDs or schemas represented in a single XML document, and (2) the desire to provide hints about a domain or schema to search engines and other indexing tools. The XML namespace facility provides for universal names my using "qualified names" in markup: a qualified name contains "a single colon, separating the name into a namespace prefix and the local name. The prefix, which is mapped to a URI, selects a namespace. The combination of the universally managed URI namespace and the local namespace produces names that are guaranteed universally unique."

The first Working Draft of the W3C XML document Namespaces in XML was released on March 27, 1998. It was produced as part of the XML Activity, and was previously released in January as a W3C 'NOTE'. The document editors are: Tim Bray (XML co-editor, Textuality), Dave Hollander (Hewlett-Packard Company), and Andrew Layman (Microsoft). References: W3CWD-xml-names-19980327, World Wide Web Consortium Working Draft 27-March-1998. The namespaces draft "describes a simple method for qualifying certain names used in Extensible Markup Language documents by associating them with namespaces, identified by URI." In the simplest case, the namespace problem is undeniable and the proposed XML namespace solution is straight-forward (indirection being required by the RFC's lexical rules for URIs). Pieces of text containing XML markup which might be "cut and pasted" across domains without respect for the (implicit or explicit) source document schemas/DTDs could result in ambiguity as well as name collision. So: declarations in the form of XML processing instructions may be put into the prolog of an XML document, as exemplified in <?xml:namespace ns="http://iso-countries.iso.org/199804.html" prefix="cn9804" ?>, and the corresponding prefixes may be added to elements, attributes and processing instructions of the source document instance: (e.g.,) <cn9804:name>Boatia</cn9804:name>. In these cases, a processor would be able to make sense of an encoded name element such as "Boatia" by referring to the authority list stored in or referenced by the resource given as a namespace identifier, viz., 'http://iso-countries.iso.org/199804.html'. Users should observe the warnings in the working draft, as well as in the cautionary note from Jon Bosak, concerning the provisional status of the syntax. The draft states: "The XML Working Group will not allow early implementation to constrain their ability to make changes to this specification prior to final release." The XML Working Group anticipates that the namespace facility presented (provisionally) in this draft will be integrated into a future version of the XML specification.

W3C announced the availability of a NOTE on Namespaces in XML, as part of the W3C XML Activity. References: NOTE-xml-names-19980119, Version 1.0, dated 19-January-1998. The editors are Tim Bray (Textuality), Dave Hollander (Hewlett-Packard Company), and Andrew Layman (Microsoft); Murata Makoto contributed the operational scenarios in the examples section. The document abstract says: "XML Namespaces is a proposal for a simple method to be used for qualifying names used in Extensible Markup Language (XML) documents by associating them with schemas, identified by URI." This NOTE submitted to the Consortium represents a formulation based upon significant prior work, some of which is referenced by entries in the XML Page. The current document is available in HTML and XML format. The NOTE may be obtained as "NOTE-xml-names" from the W3C Web site; or see the dedicated entry in the XML Page.

XML name spaces are elaborated in the NOTE summary as follows: "We envision applications of XML in which a document instance may contain markup defined in multiple schemas. These schemas may have been authored independently. One motivation for this is that writing good schemas is hard, so it is beneficial to reuse parts from existing, well-designed schemas. Another is the advantage of allowing search engines or other tools to operate over a range of documents that vary in many respects but use common names for common element types. These considerations require that document constructs should have universal names, whose scope extends beyond their containing document. This specification proposes a mechanism, XML Namespaces, to accomplish this. XML Namespaces are based on the use of qualified names, similar to those long used in programming languages. Names are permitted to contain a colon, separating the name into two parts, the namespace name and the local name. The namespace name identifies a schema's URI. The combination of the universally-managed URI namespace and the local schema namespace produces names that are guaranteed universally unique."

Principal References

• Related Resource: Resource Directory Description Language (RDDL) for namespace documents.

• [August 16, 2006] Namespaces in XML 1.0 (Second Edition) . W3C Recommendation. 16-August-2006. Edited by Tim Bray (Textuality), Dave Hollander (Contivo, Inc.), Andrew Layman (Microsoft), Richard Tobin (University of Edinburgh and Markup Technology Ltd). See also Namespaces in XML 1.1 Requirements . With errata page and public archives for 'xml-names-editor@w3.org' list.

• Namespaces in XML 1.1. W3C Recommendation. 4-February-2004 Edited by Tim Bray (Textuality), Dave Hollander (Contivo, Inc), Andrew Layman (Microsoft), and Richard Tobin (University of Edinburgh and Markup Technology Ltd). With an errata document.

• Namespaces in XML 1.1 Requirements. W3C Working Draft 03-April-2002.

• Namespaces in XML [1.0] World Wide Web Consortium. 14-January-1999. Edited by : Tim Bray (Textuality), Dave Hollander (Hewlett-Packard Company), and Andrew Layman (Microsoft). With an errata document.

• URIs for W3C Namespaces. Part a series of documents that describe W3C Technical Report Publication Policies. February 13, 2006 or later. The W3C Webmaster allocates and authorizes namespace URIs having certain forms; W3C provides the service of allocating and maintaining persistent URIs so that those URIs remain stable during discussions. "In all Member and Team Submissions, (1) Namespace URIs MUST be dereferenceable, and (2) Namespace Documents must describe the relationship between the defining specification and the namespace URI... A Namespace Document describes the namespace, providing directly or by reference information for human and also, ideally, machine consumption. A Namespace Document is available for retrieval using a corresponding namespace URI. When a namespace URI appears in a Recommendation Track document, the responsible group MUST publish a corresponding Namespace Document. In other contexts as well, groups SHOULD publish Namespace Documents."

• "The Disposition of Names in an XML Namespace." DRAFT TAG Finding of 16-December-2005. Published as an Approved TAG Finding as of January 09, 2006. Edited by Norman Walsh (Sun Microsystems, Inc). "This [draft] Finding addresses the question of whether or not adding new names to a (published) namespace is a sound practice. Namespaces are a mechanism for managing names in a distributed way that greatly reduces the likelihood that two independent parties will create the same name for different purposes. The terms in a namespace are two-part identifiers consisting of a namespace name (a URI) and a local name (an NCName as defined in (W3C XML Namespaces). Using a URI leverages the well-understood URI allocation mechanisms... Namespaces, originally designed to provide names for XML elements and attributes, have been adopted much more broadly by the web community. They are now used not simply for elements and attributes but for function names, tokens, and identifiers for ever more purposes. The xml: namespace demonstrates that some namespaces benefit from a policy that allows additional names to be defined in them over time. This does not preclude the possibility that some namespaces would benefit from a policy that forbids such extension. From these observations, we conclude that the following good practice applies: Good Practice: Specifications that define namespaces SHOULD explicitly state their policy with respect to changes in the names defined in that namespace. For namespaces that are not immutable, the specification SHOULD describe how names may be given definitions (or have them removed) and by whom. If a namespace document is provided, as WebArch Vol 1 recommends, the namespace change policy SHOULD be stated in the namespace document. As a general rule, resources on the web can and do change. In the absence of an explicit statement, one cannot infer that a namespace is immutable..."

• Associating Resources with Namespaces. W3C Draft TAG Finding of 13-December-2005 or later. Edited by Norman Walsh (Sun Microsystems, Inc). "This Finding addresses the question of how ancillary information (schemas, stylesheets, documentation, etc.) can be associated with a namespace... The names in a namespace form a collection: (1) (2) sometimes it is a collection of attribute names (XLink, for example), (3) sometimes it is a collection of functions (XQuery 1.0 and XPath 2.0 Data Model), (4) sometimes it is a collection of properties (FOAF), (5) sometimes it is a collection of concepts (WordNet), and many other uses are likely to arise. There's no requirement that the names in a namespace only identify items of a single type; elements and attributes can both come from the same namespace as could functions and concepts or any other homogeneous or heterogeneous collection you can imagine. The names in a namespace can, in theory at least, be defined to identify any thing or any number of things. Given the wide variety of things that can be identified, it follows that an equally wide variety of ancillary resources may be relevant to a namespace. A namespace may have documentation (specifications, reference material, tutorials, etc., perhaps in several formats and several languages), schemas (in any of several forms), stylesheets, software libraries, applications, or any other kind of related resource. A user, encountering a namespace might want to find any or all of these related resources. In the absence of any other information, a logical place to look for these resources, or information about them, is at the location of the namespace URI itself..."

• XML/SGML and Namespaces - Early References, Background

• "XML Namespaces FAQ." By Ronald Bourret. As referenced on XML-L: "I am pleased to announce an XML namespaces FAQ is now available... In addition to the usual details, this FAQ discusses subjects such as how namespaces are used when combining two documents, how to write documents that are both valid and namespace-compliant, and how to write namespace-aware SAX and DOM applications. Please send comments, complaints, corrections, and suggestions directly to me at: rpbourret@hotmail.com". [cache 2000-09; local archive copy, 2000年03月13日]

General References: Articles, Papers, News, Blogs

• [2010年01月01日] "XML Namespaces." By James Clark. Blog: James Clark's Random Thoughts. "[...] I have been continuing to have a dialog with some folks at Microsoft about M. This has led me to do a lot of thinking about what is good and bad about the XML family of standards. The standard I found it most hard to reach a conclusion about was XML Namespaces. On the one hand, the pain that is caused by XML Namespaces seems massively out of proportion to the benefits that they provide. Yet, every step on the process that led to the current situation with XML Namespaces seems reasonable... From a more theoretical point of view, I think the insistence on URIs for namespaces is paying insufficient attention to the distinction between instances of things and types of things. The Web works as well as it does because there is an extraordinarily large number of instances of things (i.e., Web pages) and a relatively very small number of types of things (ie MIME types). Completely different considerations apply to naming instances and naming types: both the scale and the goals are completely different. URIs are the right way to name instances of things on the Web; it doesn't follow that they are the right way to name types of things... I also have a (not very well substantiated) feeling that using URIs for namespaces tends to increase coupling between XML documents and their processing. An example is that people tend to assume that you can determine the XML schema for a document just by looking at the namespace URI of the document element... What lessons can we draw from this? For XML, what is done is done. As far as I can tell, there is zero interest amongst major vendors in cleaning up or simplifying XML. I have only two small suggestions, one for XML language designers and one for XML tool vendors: (1) For XML language designers, think whether it is really necessary to use XML Namespaces. Don't just mindlessly stick everything in a namespace because everybody else does. Using namespaces is not without cost. There is no inherent virtue in forcing users to stick xmlns=... on the document element. (2) For XML vendors, make sure your tool has good support for documents that don't use namespaces. For example, don't make the namespace URI be the only way to automatically find a schema for a document. What about future formats? First, I believe there is a real problem here and a format should define a convention (possibly with some supporting syntax) to solve the problem. Second, a solution that involves a prefix/URI duality is probably not a good approach. Third, a purely registry-based solution imposes centralization in situations where there's no need. On the other hand, a purely DNS-based solution puts all extensions on the same level, when in reality from a social perspective extensions are very different: an extension that has been standardized or has a public specification is very different from an ad hoc extension used by a single vendor. It's good if a technology encourages cooperation and coordination. My current thinking is that a blend of registry- and DNS-based approaches would be nice...

• [September 17, 2009] "Proposal for XML Namespaces in OMG Specifications." By Tom Rutt (Fujitsu). OMG Final Proposal Document. Version 1. September 17, 2009. Object Management Group (OMG), like several other consortia, sponsors an initiative to define the use of XML namespaces in technical specifications. The (draft) "Proposal for XML Namespaces in OMG Specifications" (Version 1) has been prepared for submission to the OMG Architecture Board. Document summary: "Currently, within the OMG there is no consistency in how namespaces are defined and associated with XML schemas, XMI documents, and WSDL documents for OMG Specs. Moving forward, it has been suggested that the OMG should have a policy for XML Namespaces associated with OMG specs... For consistency, the most important aspect of this proposal is that a URL used for any OMG XML namespace always resolves to a RDDL document describing that namespace, and that document be in a dated directory within the file hierarchy associated with the OMG specification which defines the namespace. The RDDL document is a special type of XHTML file, which contains explanatory text describing important aspects of the namespace definition, as well as specialized html links to related resources... This proposal specifies a specific policy for URLs used for OMG schema and WSDL descriptions, which requires that the URL used for an OMG XML namespace be in a dated directory within the directory of the OMG specification which defines the namespace. The explanatory text in the OMG RDDL document for the namespace needs to include the policy used for defining and versioning the URI used for that namespace. This proposal includes a draft of the text defining the namespace versioning policy. The use of a dated URL, rather than a fixed version number, in a namespace name allows for evolution of the namespace, through subsequent XSD files which refine the valid productions in that namespace..." [cache/archive]

• [June 27, 2008] "Associating Resources with Namespaces." By Erik Wilde. From O'Reilly News (June 27, 2008). "The W3C just published a new TAG Finding called Associating Resources with Namespaces... the finding talks about how to create namespace description documents, so that namespace names can point to helpful resources, rather than being abstract identifiers. The TAG finding breifly describes possible languages for namespace description documents (RDDL 1.0 and 2.0 and GRDDL), and describes a vocabulary of terms for describing the nature of resources being linked to in a namespace description, and what the purposes of these resources are. The definitions of these terms, though, are one-liners with little guidance to what that concept is supposed to represent. What I am missing most (and what we were concentrating on when we were defining our own format for namespace descriptions in an e-government scenario) is the ability to associate namespace descriptions themselves, and make assertions such namespace x depends on namespace y. Or rather simple but really helpful pieces of information (in particular for developers) such as namespace x is usually associated with one of these two namespace prefixes, here is where you can find test data, or here is where you can find some example data..." See "Structuring Namespace Descriptions."

• [June 26, 2008] W3C Publishes Approved TAG Finding on Associating Resources with Namespaces. From the Cover Pages. In June 2008, W3C published Associating Resources with Namespaces as an Approved TAG Finding from the W3C Technical Architecture Group (TAG). The document addresses the question of how ancillary information (schemas, stylesheets, documentation) can be associated with an XML namespace. It offers guidance on how a namespace document can be optimally designed for humans and machines such that information at the namespace URI conforms to web architecture good practice. This TAG finding addresses TAG issue 'namespaceDocument-8': "What should a namespace document look like?" The new TAG finding defines a conceptual model for identifying related resources that is simple enough to garner community consensus as a reasonable abstraction. It demonstrates how RDDL 1.0 is one possible concrete syntax for this model, and shows how other concrete syntaxes could be defined and identified in a way that would preserve the model. The specification also provides guidance on use of identifiers for indivisual terms within an XML namespace. Finally, the TAG finding discusses the use of a namespace URI as a suitable "key" for the nature of a resource encoded in an XML vocabulary, or for the purpose of a resource.

• [March 6, 2008] "Namespaces in IE 8 Beta 1." By Dave Orchard. From Dave Orchard's Blog (March 6, 2008). "MSFT just released some information on their improved namespace support in IE 8 Beta 1. The gist is (1) namespace prefix declarations on the HTML element, BUT only there; (2) default namespaces on any unknown element, BUT any children default namespaces are ignored; note this means that the xhtml default namespace is not supported; (3) Attribute Namespaces are NOT supported; (4) namespaces are handling by doing a registry search (byte for byte comparison on namespace value) for the namespace and calling the binary handler; (5) One of the Reg keys is 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\XML Namespace'; (6) the handlers for the namespaces can be installed and queried using a new API. I certainly applaud MSFT for doing more for namespaces in IE. But, MSFT still needs to do more to make this really work. The non-support for attribute namespaces kills many languages such as xlink (used by many other languages like SVG), mathML, and even MSFT et al's sml (sml:ref="true"). The lack of nested default namespaces will also kill much of the XML recursion scenarios, like MathML inside SVG. These two deficiencies are knock out punches against a very signficant number of use cases. My guess is that they are either going to fix it because they do really want to support xml nesting, or they will never fix it because they only want to support the large monolithic xml languages that are not modular and are element only, perhaps the OOXML? I still have hopes that the HTML5 working group would listen to Sam Ruby and the TAG and add namespaces in HTML5..."

• [February 22, 2008] "HTTP-based IETF Namespace URIs at IANA." Edited by Martin Dürst (Aoyama Gakuin University, Sagamihara, Kanagawa, Japan) and Tim Bray (Sun Microsystems). IETF Network Working Group, Internet Draft 'draft-duerst-iana-namespace-00.txt'. February 18, 2008, expires August 21, 2008. 8 pages. Intended status: Best Current Practice (BCP). Source: see the I-D Tracker.

  This document creates a registry and defines a procedure to allow IETF specifications to register XML Namespace Names with IANA which are HTTP URIs and thus potentially useful for looking up information about the namespace.

  Many IETF specifications use Extensible Markup Language (XML) 1.0 (Fourth Edition) [W3C Recommendation 16-August-2006, edited in place 29-September-2006] with Namespaces in XML 1.0 (Second Edition) [W3C Recommendation 16-August-2006]. XML Namespace Names are URIs, and there are many options for constructing them. One of the options is the use of HTTP URIs (those whose scheme is 'http:'). IETF RFC 3688 (The IETF XML Registry) created an IANA registry for XML namespaces based on URNs, which take on the form 'urn:ietf:params:xml:ns:foo'. RFC 3470 (Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols) observes that in the case of namespaces in the IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used to mint HTTP URIs. However, it seems to be more appropriate and in line with IETF practice to delegate such a registry function to IANA... IANA maintains a registry page listing the registered XML namespaces which use HTTP URIs. For each registered namespace, the registry page includes a human-readable name for the namespace, a link to the namespace document, and the actual namespace URI.

  Namespaces created by IANA upon registration have the following form. There is a common prefix, http://www.iana.org/xmlns/ [...] followed by a unique identifier. The unique identifier should be a relatively short string of US-ASCII letters, digits, and hyphens, where a digit cannot appear in first position and a hyphen cannot appear in first or last position or in successive positions. In addition, the unique identifier can end in a single '/' or '#'. XML namespaces are case-sensitive, but all registrations are required to mutually differ even under case-insensitive comparison. For uniformity, only lower letters should be used. A unique identifier is proposed by the requester, but IANA may change it as they see fit, in consultation with the responsible Expert Reviewer.

  For each namespace registered, there must be a namespace document in either HTML or XHTML which may be retrieved using the HTTP URI which is the registered namespace name. It contains the template information with appropriate markup. The request for creation and registration of a HTTP XML Namespace URI is made by including a completed registration template in the IANA Considerations section of an Internet-Draft. Registration is limited to namespace names specified in documents that go through IESG approval and where change control lies with the IETF. There is no review procedure separate from the procedure leading to IESG approval. The actual registration is carried out as part of the work that IANA does in scanning and processing documents being published as RFCs.

  Benefits of HTTP URIs: Software which uses XML namespace names typically treats them at opaque strings at runtime, using them to decide whether some particular markup tokens are to be selected for some particular processing. Such software should have no concern at runtime for the URI scheme. Thus, all properly-registered URI schemes are equally suitable for runtime use. HTTP URIs are distinguished by being associated with a widely-deployed protocol. They can be used not only to identify, but also to retrieve Web Resources. Thus, a human who recognizes an HTTP URI may reasonably attempt to so use it. Note that this usage is entirely unrelated to its runtime use in unambiguously naming markup tokens. Thus, HTTP URIs have the advantage that they may be usable by humans (typically protocol implementors in this context) to educate themselves about the nature and purpose of the markup tokens that are in the namespace in question. A subsidiary benefit is that HTTP URIs tend to be substantially more human-readable than URNs, and thus more memorable. Note that the use of an HTTP URI does not constitute an obligation to make it dereferencable. Runtime software must not depend on whether dereferencing is possible. The advantages only apply to human use and in a pedagogic context..."

• [August 28, 2006] CSS Module: Namespaces . W3C Working Draft. 28-August-2006. Latest version URI: http://www.w3.org/TR/css3-namespace Previous version URI: http://www.w3.org/1999/06/25/WD-css3-namespace-19990625/. Edited by Elika J. Etemad. Previous Editors: Peter Linss (Netscape Communications) and Chris Lilley (W3C). "This CSS module defines the syntax for using namespaces in CSS. It introduces the @namespace rule for declaring the default namespace and binding namespaces to namespace prefixes, and it defines a syntax that other specifications can adopt for using those prefixes in namespace-qualified names. A CSS client that does not support this module will (if it properly conforms to CSS forward compatible parsing rules) ignore all @namespace rules, as well as all style rules that make use of namespace qualified names. The syntax of delimiting namespace prefixes in CSS was deliberately chosen so that these CSS clients would ignore the style rules rather than possibly match them incorrectly... In CSS Namespaces, as in XML Namespaces, the local prefix is merely a syntactic construct; it is the expanded name (the tuple of local name and namespace) that is significant. Thus the actual prefixes used in a CSS style sheet, and whether they are defaulted or not, are independent of the namespace prefixes used in the markup and whether these are defaulted or not... The namespace prefix is declared only within the style sheet in which its @namespace rule appears, and not any style sheets imported by that style sheet, style sheets that import that style sheet, or any other style sheets applying to the document..."

• [July 29, 2006] "XMLVS: Using Namespace Documents for XML Versioning." By Harry Halpin (School of Informatics, University of Edinburgh). Prepared for presentation at the Extreme Markup Languages 2006 Conference, August 7-11, 2006 Montréal, Canada. "What is the relationship among languages, URIs, namespaces, and namespace documents? What ought it to be? Recent discussion has clarified the utility of having namespace documents dereferenceable from the namespace URI, but current practice in the formulation of namespace documents is inconsistent and exhibits serious semantic gaps. A better approach to namespace documents can provide not only better and more consistent information about namespaces and the names in them but also help with the problem of namespace versioning. XMLVS, an XML Version System for XML Languages, provides a concrete language for managing namespace documents; it can be serialized both as human-readable XHTML RDDL documents and (if the strict version of XMLVS is used) also RDF documents. When used with the Social Versioning System (a version-control system), XMLVS allows for easy maintenance of namespace documents in line with current W3C Recommendations, and suggests some solutions for problems caused by shortcomings in current standards." See an online draft [cache].

• [May 26, 2006] "Structuring Namespace Descriptions." By Erik Wilde (ETH Zurich, Switzerland). In Proceedings of the Fifteenth International Conference on World Wide Web (WWW 2006), Edinburgh, Scotland. May 23 - 26, 2006. WWW 2006 Poster Track. Also available online in PDF format, and from ACM. "Namespaces are a central building block of XML technologies today, they provide the identification mechanism for many XML-related vocabularies. Despite their ubiquity, there is no established mechanism for describing namespaces, and in particular for describing the dependencies of namespaces. We propose a simple model for describing namespaces and their dependencies. Using these descriptions, it is possible to compile directories of namespaces providing searchable and browsable namespace descriptions... For small and self-contained projects or scenarios, namespace documents may provide a convenient way to provide access to information associated with a namespace, but in most cases this information is available and well-known anyway. In larger and more complex scenarios without central coordination, namespace documents provide a much more needed service, because they serve as the hub for information about namespaces. By collecting and publishing namespace documents in such a scenario, it is then possible to provide a directory of namespace descriptions... We have applied the model proposed here to the area of e-Government in Switzerland, where a large number of XML-related vocabularies exist, some of them defined by various Swiss authorities, some of them adopted from standardization organizations or other bodies. This initial collection of namespaces has been described, and this set of descriptions has been augmented with descriptions of some of the core namespaces of XML-related standards. This set of namespace descriptions has been compiled into a directory of Swiss e-government namespaces..." [cache PDF]

• [March 24, 2006] Signatures and Namespaces. By John M. Boyer (IBM Victoria Software Lab). March 01, 2006 or later. See the image file. "A namespace starts out with just two words, W1 and W2; Build implementation that supports rendition of the vocabulary; Later, requirements grow and shift; Need to change meaning of W2 to W2'; Need to add word W3; Create new implementation to support new features; Create document in new implementation containing W1, W2' and W3; Sign document; Send document to user with original implementation; Document validates, so it is "secure"; User only sees or experiences W1 and W2 (original meaning, not primed meaning). Typical software behavior is to ignore W3 as not understood; This is why namespace volatility corrupts signatures; Security experts throw out hash algorithms over significantly smaller infractions..."

• [March 24, 2006] "I was wrong (sort of) about namespaces." By Eliot Kimber. From Dr. Macro's XML Rants Blog (Sunday, February 26, 2006). "... As we were putting the final brush strokes on the XML 1.0 Recommendation (almost 10 years ago now — hard to believe) we started working on 'namespaces for XML'. At the time I was quite vocal in my opposition to namespaces on the grounds that they didn't really solve any problems, were misguided, and totally missed the point. I was also very upset, if memory serves, about the issue of using attributes to declare namespaces rather than processing instructions... In my mind the whole XML thing was going off the rails just as we needed to focus on the really important stuff, namely XLink... Boy was I wrong. Mostly. Sort of... My objections to namespaces as they were being formulated (and as they subsequently got defined) were: (1) There was no standard mechanism for defining membership of names in a namespace; (2) There was no standard mechanism for binding a given namespace to an abstract application; (3) Using attributes to declare namespaces was just wrong wrong wrong; (4) Namespaces didn't really solve the interoperation problems that people had or perceived... eventually XSD schemas (and I should think, all other XML document constraint specification mechanisms designed since the publication of the namespace spec) did provide a way to bind document types to namespaces. This still doesn't formally define the finite set of members in a namespace but it does let you define a set of names for the namespace. The subtle difference here is that the definition of the set of names points to the namespace rather than the namespace pointing to the definition. Think about that for a moment — the only standard-defined thing that represents a namespace (per the namespace spec) is the namespace URI — there is no requirement (or even expectation) that that URI be resolvable to any resource. A naive person (or a person steeped in big-systems declare everything think) might expect that a namespace URI would always resolve to a resource that describes the namespace as an object. From a pure engineering/mathematical completeness standpoint that seems like a reasonable thing —- anything you can name should have a concrete representation: 'Damnit Spock, there needs to be an object!' So why don't namespaces have this? Simple answer: because they didn't need them in order to be useful. That's the beauty of the Web: it's agile methods at work — the simplest thing that could possibly work..." [Editor's note: Eliot Kimber (Innodata Isogen) is an impressive person, in many ways, including his tendency not to waver on convictions strongly held; in counterpoint, the exemplary model of "but I changed my mind, I was wrong" (above) serves as a further reminder of one character trait that makes great people great. It's rare, and I admire it. Kudos, Eliot. Honest and truth are part of good science, and they always win over cheap substitutes commonly offered.]

• [March 17, 2006] "The Fiasco of XML Attributes and Namespaces." By John Boyer (Senior Product Architect, IBM Workplace Forms). Frustration giving way to blogation: "XML namespaces rec (pardon the pun) states that an attribute which is namespace unqualified is 'local' to an element and is uniquely identified by a combination of the attribute local name and the type and namespace URI of the containing element. The word identify really should be used more sparingly, as here is a case where its misuse has caused years of confusion and acrimony in the XML community. An identifier is something that established the identity of something else. You cannot have two things associated with the same identifier unless they are identical things. I am often frustrated by seasoned W3C folks who say that 'this depends on your definition of identify' and honestly believe this is a defense of the confusion in the namespaces rec. This is like saying ot me, 'Well you're right unless you have a definition for identify that doesn't identify things, which is what we did at the W3C...' Interestingly, the XHTML working group came up with a fascinating example where it is legitimate and sensible to have a global and local attribute with the same local name but completely different meanings. It has to do with the next version of XML events. After hours of discussion, the decision was that they weren't going to do that (second answer above). Not because it's illegal, but because it's too subtle for most XML people. Well, the XHTML group may change their minds, but even if they don't, the example is really worth understanding because it actually makes sense why you'd want to have the two attributes mean something different...."

• [October 16, 2005] "Namespaces A Mess?" By Michael Kay Michael Kay. Posted to XML-DEV. October 16, 2005. "...look at the xsl-list archives and see the proportion of user problems that are caused by namespaces. Or, if you were able, look at the minutes of any W3C working group and see the proportion of its effort that goes into dealing with the complexities caused by namespaces. The main issues are: (a) exactly what strings are permitted as namespace URIs? Different specs differ on the point. (b) are namespace declarations information-bearing? (c) are in-scope namespaces that are not referenced information-bearing? (d) are prefixes information-bearing? (e) how should namespaces be handled by applications that allow a document to be modified? (f) DTDs are an intrinsic part of XML, but DTDs are not namespace-aware. (g) How should namespaces be versioned? At a higher level, namespaces cause immense design difficulty. How should a large organization creating hundreds of XML document definitions manage its allocation of namespaces? You could say that any naming scheme would have this problem. However, the design of XML namespaces is optimized for situations in which the number of namespaces is small (more than five in a document gets unwieldy). This makes namespace management very difficult. There's a basic root cause of many of the difficulties, which is that naming in any information architecture is absolutely fundamental, yet the naming architecture of XML has been "patched in" as an afterthought at a layer above the core. That, plus the fact that the information model itself (the infoset) is non-prescriptive and layered above the core..." [source]

• [June 29, 2005] "namespaceDocument-8 Notes." By Norman Walsh, prepared for the W3C TAG. Updated 29 June 2005. See the associated posting of June 24, 2005, "Revisiting namespaceDocument-8." See http://www.w3.org/2001/tag/2005/06/23-rddl/ for possible subsequent update. "At the recent f2f, the TAG discussed namespaceDocument-8 again and considered how we might make progress. I've published an outline of our ideas ... with some examples. The central idea is to get past the roadblock of picking a single format by employing GRDDL..." See "Resource Directory Description Language (RDDL)."

• [April 13, 2005] "XML Namespaces Don't Need URIs." By Michael Day. From XML.com (April 13, 2005). [Opinion:] "The decision to identify XML namespaces with URIs was an architectural mistake that has caused much suffering for XML users and needless complexity for XML tools. Removing namespace URIs altogether and simply using namespace prefixes to identify namespaces would make it easier for people as well as software to read, write, and process XML." Day's complaints: (1) Namespace URIs Have Terrible Syntax: ... namespace URIs tend to be long and cryptic, with lots of punctuation and case-sensitive text; (2) HTTP URIs Are a Poor Choice for Namespaces: HTTP URIs are often used as namespace URIs; however, most software treats HTTP URIs as resource locators, not identifiers; (3) Namespace URIs Don't Help People Read or Write XML: Namespace URIs give people the ability to write XML documents with arbitrary prefixes like <foo:schema> or <superluminal:transform>, but people don't do that, sensibly enough, as it would be confusing and serve no purpose. Since people are already identifying namespaces using sensible namespace prefixes, having to write the namespace URIs as well is just a hindrance. Namespace URIs don't help people to read XML documents either; they add an unnecessary level of indirection that makes XML documents harder to interpret... For XML, it may already be too late to remove namespace URIs. While the XML specification itself does not depend on them, enough implementations already do so that it may be impractical to effect a change. However, there are still steps that can be taken when designing XML vocabularies to minimize the problems that namespace URIs cause. Carefully consider whether namespaces are really necessary. Many XML vocabularies don't need them, so don't feel compelled to use them without good reason..."

• [March 07, 2005] "Use RDDL instead of XML Schema at the Namespace URI?" By Jonathan Marsh. Posted to the W3C Public discussion list of the Web Services Addressing Working Group. Thursday, March 07, 2005. Proposal in the context of WS-Addressing spec design. "Proposal: Place a RDDL document at each of the namespace URIs defined by WS-A. Provide a 'latest schema' link as well as dated links to the schema. State in the document that the resources (schemas) at the dated links are immutable, the list of dated schemas may grow to incorporate fixes, and the latest schema link will always point to the latest." Justification: "One advantage of RDDL is that it would enable one to discover, through the namespace URI, a number of schemas for the namespace. This is especially interesting when errata are taken into account. The WS-I BP promulgated some fixes to the WSDL 1.1 schema, but since it is also desirable to have a stable document at the namespace URI, it published alternative dated versions with various fixes in them, and pointed to those dated versions from the spec. It might have been simpler and more discoverable to find all the related (dated) schemas through a RDDL document at the namespace URI..." There is an example WSA RDDL online. Background: In a previous message it was noted that three "namespace" documents (at 'http://www.w3.org/2005/03/addressing/reply', 'http://www.w3.org/2005/03/addressing/role/anonymous', 'http://www.w3.org/2005/03/addressing/feature') "all link back to dated versions of the core and soap binding specs... Unfortunately, the links are broken!" [they were fixed, but it served as an example of why a RDDL document may be useful for versioning. In the January 18, 2004 version of "Resource Directory Description Language (RDDL) 2.0" the editors stated: "It is the consensus of the TAG that RDDL is a suitable format for use as a "Namespace Document", that is to say as a representation yielded by dereferencing a URI in use as an XML Namespace Name. While this document has no official standing, it is the intention of the TAG to seek guidance from the W3C membership and the larger community on the question of whether and how to progress this document and the use of RDDL." Other (February 2005 TAG thread) references: Jonathan Borden [RDDL -> RDF], Stuart Williams, Dan Connolly.

• [December 16, 2004] "The QName URN Namespace." By David Orchard (BEA Systems, Inc) and Rich Salz (DataPower Technology, Inc). IETF Network Working Group. Internet Draft. Reference: 'draft-rsalz-qname-urn-00.txt'. December 9, 2004, expires June 9, 2005. "This specification defines a Uniform Resource Name namespace for XML namespace-qualified names, QNames. As long as the URN is encoded in the same character set as the document containing the original QName, the Qname URN provides enough information to maintain the semantics, and optionally the exact syntax, of the original name. There are a variety of situations when a QName may need to be mapped to a URI. For example, when exchanging (or referencing) an identifier for an XML element contained within a document, and the medium of exchange prefers URIs to QNames, such as an XML Schema anyURI data type. Another scenario is for comparing the identifiers, which can be simpler by comparing just a string without having to also compare the context setting XML namespace attribute that may be declared arbitrarily earlier in the document. The [W3C] XML Namespaces specification does not provide a canonical mapping between QNames and URIs. Any XML specification that wants to enable identifier exchanges must define a language specific QName to URI mapping. There have emerged a variety of different algorithms and solutions for the mapping. To date, there have been no standardized algorithms available that they can re-use, which has increased their efforts. A standardized mapping, such as this, should provide increased productivity. Almost all of the algorithms for Qname to URI mappings are based upon concatenation of the URI and the name with variations based upon prefix inclusion, namespace name and name separator, etc. These are typically problematic because it is difficult to recover the QName from the URI as the namespace name and name separator may have already been used in the namespace name. Having the namespace name at the end of the identifier string avoids these and other problems..." From (ephemeral) IETF URL: http://www.ietf.org/internet-drafts/draft-rsalz-qname-urn-00.txt.

• [April 06, 2004] "Use XML Namespaces With Care. Minimizing Problems While Incorporating Namespaces into XML Design." By Uche Ogbuji (Principal Consultant, Fourthought, Inc). From IBM developerWorks (April 06, 2004). "Most regular users of XML are quite familiar with XML namespaces and accept them as a basic part of XML. They shake their heads at the occasional oddities of namespaces, but in general don't give them all that much thought. Among XML experts, however, XML namespaces have been very controversial from day one. This controversy is for good reason: Namespaces solve a difficult problem and are one of many approaches to solving this problem, each of which has its pros and cons. The W3C XML namespaces specification is a compromise, and as with all compromises, it often falls short of addressing each user's needs. Even after all this time, namespaces have proven very difficult to incorporate smoothly into XML information architecture, and lack of care with namespaces can cause a lot of complications for XML processing tools. In this article, I go over design considerations that can help you avoid such problems when using XML namespaces. In general my suggested guidelines will be in boldface. This article will cover XML namespaces 1.0 (including all errata). XML namespaces 1.1 is mercifully modest in its changes, but it is a brand new specification and isn't yet well supported by the tools. I expect that XML namespaces 1.1 will soon become the norm... XML namespaces seem simple on their face, but buried in their nuances is the danger of real complexity and clumsiness if you don't take care while using them. Understand thoroughly the meaning, rules, and implications of the various concepts that make up the XML namespaces mechanism, and stick consistently to simple conventions while designing vocabularies using namespaces and creating actual instance documents..."

• [January 18, 2004] "Resource Directory Description Language (RDDL) 2.0." Edited by Jonathan Borden (The Open Healthcare Group) and Tim Bray (Antarctica Systems). Version: January 18, 2004. Latest Version URL: http://www.rddl.org/rddl2. Previous Version ('1.x'): February 18, 2002. Status: "This document is a working draft that contains substantial input from the W3C Technical Architecture Group, produced in connection with the work on its issue namespaceDocument-8. It is the consensus of the TAG that RDDL is a suitable format for use as a 'Namespace Document', that is to say as a representation yielded by dereferencing a URI in use as an XML Namespace Name. While this document has no official standing, it is the intention of the TAG to seek guidance from the W3C membership and the larger community on the question of whether and how to progress this document and the use of RDDL..." Introduction: "This document describes the Resource Directory Description Language (RDDL). A RDDL document, called a Resource Directory, provides a package of information about some target, including: (1) Human-readable descriptive material about the target (2) A directory of individual resources related to the target, each directory entry containing descriptive material and linked to the resource in question. The targets which RDDL was designed to describe are XML Namespaces. Examples of "individual related resources" include schemas, stylesheets, and executable code designed to process markup from some namespace. A Resource Directory is designed to be suitable for service as the body of an entity returned by dereferencing a URI serving as an XML Namespace name. The Resource Directory Description Language is an extension of XHTML Basic 1.0 with two added attributes of the a element, named rddl:nature and rddl:purpose. See URIs For Commonly Defined Link Purposes and URIs For Common Natures of Resources. General references: "Resource Directory Description Language (RDDL)."

• [August 2003] Recommended XML Namespace for Government Organizations. By Jessica L. Glace and Mark R. Crawford. Logistics Management Institute. Reference: GS301L1. August 2003. 16 pages. "Namespace associations allow XML implementers to use diverse XML vocabularies without fear of name collision resulting in invalid XML. To ensure consistency, organizations should decide on a namespace strategy and a naming convention when establishing organizational namespaces. The federal government is actively engaged in developing and deploying XML. It is critical that the government establish a cohesive, coordinated namespace approach to support its various XML efforts. This namespace approach must define a standardized structure for federal namespace as well as establish a standardized naming convention for those namespaces. Without such a coordinated approach, individual government organizations will create a proliferation of disparate XML namespace structures and names resulting in chaotic management of XML components. Given the ever expanding proliferation of federal namespaces, it is crucial that this strategy be put in place as quickly as possible since harmonizing the namespace structure and names used by different government organizations will become increasingly difficult over time. The [US] General Services Administration (GSA) asked LMI to recommend a strategy and naming convention that could be used throughout the government. This strategy is intended to be a central source of guidance to enable all trading partners of the U.S. government to develop their XML namespaces using a common strategy. This XML namespace strategy also will promote an organized roll-out of the government's ever-expanding array of XML components. In this report we describe three options for deciding an architectural namespace strategy — no namespace, single namespace, and multiple namespaces — and provide recommendations on the use of each. We also explore the use of the Uniform Resource Name (URN) and Uniform Resource Locator (URL) variants of Uniform Resource Indicators (URIs) for a government namespace naming convention and provide recommendations for their use. Finally, we outline the actions necessary to implement our recommendations..." [cache]

• [June 19, 2003] Namespace Routing Language (NRL) Supports Multiple Independent Namespaces. James Clark has announced the publication of a Namespace Routing Language (NRL) specification. NRL is "an XML language for combining schemas for multiple namespaces; it allow the schemas that it combines to use arbitrary schema languages." The release includes a tutorial and specification document and a sample implementation in the Jing (RELAX NG Validator in Java) distribution. NRL "is the successor to Clark's Modular Namespaces (MNS) language and is intended to be another step on the path towards Document Schema Definition Languages (DSDL) Part 4." The W3C XML Namespaces Recommendation itself "allows an XML document to be composed of elements and attributes from multiple independent namespaces: each of these namespaces may have its own schema and the schemas for different namespaces may be in different schema languages. The problem then arises of how the schemas can be composed in order to allow validation of the complete document." The Namespace Routing Language attempts to solve this problem. Among the features and benefits of NRL: it supports schema language coexistence, allows extension of schemas not designed to be extended, makes authoring of extensible schemas easier supports 'transparent' namespaces, allows contextual control of extension, and allows concurrent validation. "For RELAX NG, it can be used to provide some of the namespace-based modularity features that are built-in to XSD. NRL is designed to allow an implementation to stream, and the sample implementation does so. The sample implementation has a SAX-based plug-in architecture that allows new schema languages to be added dynamically. It comes with support for RELAX NG (both XML and compact syntax), W3C XML Schema (via a wrapper around Xerces-J), Schematron, and (recursively) NRL; it can also use any schema language with an implementation that supports the JARV interface."

• [August 09, 2003] "XML Namespaces and Training Wheels. It Would Help to Have Tools to Avoid Creating Problems for Downstream Applications." By Jon Udell. In InfoWorld (August 08, 2003). "There is an ongoing controversy in the XML world about the use of a feature called namespaces. By default, every element in an XML document is assigned to the "empty" namespace, but the document's root element -- or any contained element -- can be assigned to another namespace, identified by a URI (Universal Resource Identifier). The idea is to be able to mix and match XML vocabularies in a modular way. For example, my Weblog's RSS 2.0 feed includes an experimental element, called <body>, which lives in the XHTML (eXtensible HTML) namespace, not in the (empty) RSS namespace... [But] clearly there's something counter-intuitive about XML namespaces... In general, we don't have much experience creating and using simple XML vocabularies, never mind mixed ones. InfoPath, the first application making a serious bid to enable mainstream folks to routinely gather and use XML data, hasn't even shipped. I think the creators of InfoPath and similar tools -- who hope that use of modular XML vocabularies will turn out to be like riding a bicycle -- ought to provide some training wheels. One thing that complicates use of namespaces, for example, is that their effects on downstream XML applications can be hard to predict. There are a number of equivalent ways to write a mixed-namespace document. But for downstream applications, such as structured search, some of those ways make life much harder than others. Tools that help us visualize the effects of mixing namespaces are an example of what I mean by training wheels. We're going to need them..."

• [November 08, 2002] "Plan to Use XML Namespaces, Part 2: Combine XML Vocabularies and Define Vocabularies of Your Own." By David Marston (Engineer, IBM Research). From IBM developerWorks. November 1, 2002. Updated 29 April 2004 or later. [This two-part article introduces XML namespaces, explores their practical benefits, and shows you how they are used in the standard XML formats and tools defined by the W3C. In part 2, David shows you how to intermix XML vocabularies and define vocabularies of your own, with several best practices highlighted. Best practices range from terminology usage up through system-wide design. The article mentions changes proposed up through the September 2002 'Last Call Working Draft' of version 1.1 of Namespaces in XML.'] "Part 1 shows how the World Wide Web Consortium (W3C) establishes precedents in its own use of XML namespaces. Part 1 also presented a consistent set of terms for use in discussions on this topic. The most substantial discussions will be about establishing your own XML vocabularies..." The 'Best practice summary' includes advice on: (1) planning your namespaces ["Establish logical and consistent prefix names to boost developer productivity; Use prefixes everywhere or at least use them on all items except those that are the real content being delivered to the end user; Apply namespaces to your own vocabulary, even when there is just one; Treat namespaces as a way to separate or isolate terms that may otherwise seem similar; When designing two vocabularies that have some elements in common, choose one namespace (possibly separate from the original two) to hold the common items; Use HTTP URLs for your URIs, without fragment identifiers; Coordinate URI naming under your domain name just as you do for names of machines on your network and your Web URLs; Change the namespace URI for every substantive change to the vocabulary, including the addition of new elements forming a strict superset of the old vocabulary"], (2) usage of namespaces inside XML documents, and (3) documentation and conversational usage.

• [November 08, 2002] "Plan to Use XML Namespaces, Part 1. The Best Ways to Use XML Namespaces to Your Advantage." By David Marston (Engineer, IBM Research). From IBM developerWorks, XML Zone. November 2002. ['This article introduces XML namespaces, explores their practical benefits, and shows you how they are used in the standard XML formats and tools defined by the W3C. Several W3C specifications are mentioned, notably XML Schema and XSLT, which offer useful ideas for using namespaces to your advantage. Best practices range from terminology usage up through system-wide design. This document mentions changes proposed up through the September 2002 "Last Call Working Draft" of version 1.1 of Namespaces in XML.'] "Most business and communications problems that XML can solve require a combination of several XML vocabularies. (You may read tag and attribute sets in place of the term XML vocabularies if you wish.) XML has a mechanism for qualifying names to be allocated into different namespaces, such as namespaces that apply to different industries. A company or (better yet) an industry consortium can assign names to elements and use common words like 'title' or 'state' without worrying that those names will clash with the same names used in another vocabulary. XML namespaces also allow names to evolve over time. After using the first version of a vocabulary, your real-world experience may lead you to devise an enhanced vocabulary. The new version can be assigned to a different namespace, and you can use XSLT to transform data from one vocabulary to the other... XML namespaces also allow various tools that process XML, such as a stylesheet-driven XSLT processor, to pick out the instructions they should obey and treat instructions for other processors as just more data. The processor is set up to consider elements from a particular namespace (or two) to be the instructions. Elements that have no namespace are data, as are all elements that have a namespace other than those recognized as instructions... Part 2 provides more depth on the best way to establish your own XML vocabularies. In Part 2, you'll also see renaming techniques that are namespace-aware..."

• [September 19, 2002] "Understanding XML Namespaces." By Aaron Skonnard (DevelopMentor). First published in MSDN Magazine, July 2001. Updated July 2002. "Namespaces are the source of much confusion in XML, especially for those new to the technology. Most of the questions that I receive from readers, students, and conference attendees are related to namespaces in one way or another. It's actually kind of ironic since the Namespaces in XML Recommendation is one of the shorter XML specifications, coming in at just under 10 pages, excluding appendices. The confusion, however, is related to namespace semantics as opposed to the syntax outlined by the specification. To fully understand XML namespaces, you must know what a namespace is, how namespaces are defined, and how they are used. The rest of this column is dedicated to answering these three questions, both syntactically and abstractly. By the time you finish reading this, you'll understand how namespaces affect the family of XML technologies... A namespace is a set of names in which all names are unique. For example, the names of my children could be thought of as a namespace, as could the names of California corporations, the names of C++ type identifiers, or the names of Internet domains. Any logically related set of names in which each name must be unique is a namespace... A namespace is a set of names in which all names are unique. Namespaces in XML make it possible to give elements and attributes unique names. Although namespaces tend to be the source of much confusion, they're easy to comprehend once you become familiar with how they're defined and used, both syntactically and abstractly..."

• [April 11, 2002] "XML Namespaces." By Sean McGrath (Propylon). From ITWorld (April 11, 2002). Column 'XML In Practice', an online "guide which explores how to write well-formed XML documents, model business requirements using XML, how to integrate XML with existing applications." ['Namespaces have been causing major disruptions throughout the XML world since their inception. As another such disturbance erupts, the time has come to reevaluate their value.] "Ostensibly, the namespace Rec is just a simple way of allowing element type names to be globally unique. Unfortunately, in so doing, it introduces rules for defaulting namespaces that significantly complicates any software it touches. XPath, SAX, DOM, XQuery, XSchema, and XSLT -- all of these are caught up in the flapping of the namespace Rec's wings, and it is not a pretty sight! I won't go into the details here, but type any of the previous words into a search engine along with 'namespace' and 'problem' and you will see what I mean. Recently, the W3C introduced a draft of version 1.1 of the namespace Rec. The changes suggested are minor but have caused the namespace debate to erupt again on xml-dev... When someone as knowledgeable as Joe English starts classifying compliant namespace usage patterns into categories called 'neurotic', 'borderline', and 'psychotic', it behooves us to take a step back and look at what is going on here! When the XML world revisits its fundamentals (around 2008 I suspect as these things always take a decade), namespaces will need to have their wings well and truly clipped in order to redress some of the chaos and damage caused from a decade of inconsiderate flapping. My advice: Don't use namespaces at all if you can avoid it. If you can't, then only put them on the root element. Oh, and don't lend money to anyone who tries to tell you namespaces are simple..." References: (1) the thread in XML-DEV postings; (2) the news item, W3C XML Core Working Group Publishes New Working Drafts for Namespaces in XML."

• [April 11, 2002] "XML Namespaces 1.1." Commentary on the new W3C WDs, by Leigh Dodds. From XML.com [XML Deviant]. April 10, 2002. "Namespaces have probably generated more debate and confusion than any other W3C Recommendation. With the first publication of a Working Draft for Namespace 1.1, which has caused a great surge of discussion on XML-DEV, it seems like the next iteration of the specification won't be any less controversial. Looking through the color coded changes in the new Namespaces in XML 1.1 Working Draft will quickly demonstrate that the document includes minimal changes from the original. Turning to the accompanying requirements document shows that this is entirely intentional. Barring the addition of some minor errata, Namespaces 1.1 will incorporate only a single extra feature, the ability to undeclare a namespace prefix. Putting the changes in context, the requirements also explain that the new specification is to be progressed to Recommendation alongside XML 1.1. Richard Tobin clarified the relationship between the two specifications in an XML-DEV posting: 'It's intended that Namespaces 1.1 will be strongly tied to XML 1.1, so that it will only apply to XML 1.1 documents. XML 1.0-only parsers will reject documents labeled 1.1 anyway, and Namespaces-1.1-aware processors will apply Namespaces 1.0 to 1.0 documents and Namespaces 1.1 to 1.1 documents.' ... As Ronald Bourret's Namespace FAQ explains, while it's possible to undeclare the default namespace, it's not possible to undeclare a namespace associated with a prefix. According to the Namespace 1.1 requirements document this is a significant problem that is affecting several other W3C specifications, including XQuery, SOAP, and XInclude... The precise problem is that, according to the XML Infoset, each element has a number of ' namespace information items', one for each of the namespace declarations currently in-scope for that element. An in-scope namespace is any namespace declared on an individual element or one of it's ancestors. This is problematic because each element ends up carrying around additional 'baggage' in the form of namespace declarations that it doesn't need... One proposal floated during the discussion combining the XML and Namespaces specifications into a single core document. Opinions were divided on whether this was a good suggestion. Some see XML and Namespaces as the real foundation. Others wanted the continued freedom to ignore Namespaces or perhaps adopt alternatives. Tim Bray's Skunkworks XML 2.0 was cited as an example of how this might combination might be achieved, although this raised some additional concerns as Bray's document also removes DTDs from the core specification. This lead to a subsequent discussion on how DTDs could be updated to better support XML Namespaces. The entire thread is too lengthy to summarize here, but it's interesting to note that the ISO DSDL project has a section devoted to 'Namespace-aware processing with DTD syntax' which may yet see this work happen outside of the W3C. In the short term, and despite loud comments from the community, the scope of changes for XML 1.1 and XML Namespaces 1.1 won't be altered beyond their currently stated requirements as Richard Tobin made absolutely clear: ['XML 1.1 aims to resolve various character-level issues (newer Unicode versions, line ends, Unicode normalization). Namespaces 1.1 aims to add undeclaring of prefixes. Both will incorporate errata to the current editions. That's all. No throwing out DTDs, no making them work with namespaces. No unification of the two specs...'] . Whether a more substantial reworking to further rationalize these and other specifications will happen is anyone's guess." References: (1) the thread in XML-DEV postings; (2) the news item, W3C XML Core Working Group Publishes New Working Drafts for Namespaces in XML."

• [February 18, 2002] "Architectural Theses on Namespaces and Namespace Documents." By Tim Bray. ['This document represents only the opinion of its author and has not been reviewed or approved by any other person or organization.'] "A namespace name is defined to be a URI reference. Some URI references may be dereferenced; when this is done, the result is referred to as the namespace document. In December 2000, I co-edited a proposal for Resource Directory Definition Language, an extension of XHTML with a <rddl:resource> element, designed for use in namespace documents. This document is as an outline of the architectural principles which led to the design of RDDL, although they were not thought through in this level of detail at that time. [...] (1) It is not strictly necessary for namespace documents to exist. (2) Namespaces vary widely in semantic effect. (3) Namespaces have definitive material... [theses #4-14 follow]" Referenced in XML-DEV 2002年02月18日: "I have just posted some arguments about namespaces and namespace documents as a contribution to TAG debate - I suspect many here will be interested; see [the posting]..."

• [February 04, 2002] "The 'xmlns:' URI Scheme for XML Namespace Reification and Namespace Prefix Declaration." By Patrick Stickler (Nokia Research Center, Tampere, FI). IETF Network Working Group, Internet-Draft. January 16, 2002. Reference: 'draft-pstickler-xmlns-00'. "This document describes the 'xmlns:' Uniform Resource Identifier (URI) scheme for the reification of XML namespaces and namespace prefix declarations... The 'xmlns:' URI scheme is intended to provide a simple but consistent means by which XML Namespaces can be reified, and which also provides for the association of a namespace prefix with a given namespace. The 'xmlns:' URI scheme belongs to the class of URIs known as Uniform Resource Values (URV) which are themselves a subclass of Uniform Resource Primitives (URP), a class of URI which constitutes a 'WYSIWYG' URI, one which is not dereferencible to and does not denote another web resource, but constitutes a self-contained resource where the full realization of that resource is expressed in the URI itself. ... Because a URP is not dereferencible, and hence does not permit the suffixation of a fragment identifier (there is no such thing as a URP Reference), it is not necessary to escape any hash marks '#' occurring in the namespace URI Reference part of a 'xmlns:' URI..." See also (1) "An Extended Class Taxonomy of Uniform Resource Identifier Schemes" [January 2002]; (2) "The 'qname:' URI Scheme for XML Namespace Qualified Names," IETF 'draft-pstickler-qname-00', which "describes the 'qname:' Uniform Resource Identifier (URI) scheme for the representation of XML Namespace qualified names."

• [February 07, 2002] "The Value of Names in Attributes. The Future of History." By Kendall Grant Clark. From XML.com. February 06, 2002. ['Kendall Clark reports on recent debate in the XML developer community over the use of qualified names in attribute values, as employed by XSLT and W3C XML Schema.'] "Namespaces in Attribute Values: The latest scuffle in the long namespace saga concerns qualified names in attribute values, the use of which has prompted some XML programmers, outside the confines of the XML-DEV mailing list, to question the value of attributes at all... That the developer community disagrees about the utility, the design, the impact, and the implementation of qualified names in attribute values is a very good indication that it is a widely, essentially contested issue. I suspect that it, like many such issues, will inevitably be presented to the W3C's Technical Architecture Group, the TAG, for adjudication; which, as we will discover, does not mean that the TAG will actually decide the issue. The TAG bottleneck..."

• [January 28, 2002] "V3 Proposal: Namespace Manager Function." By Joseph M. Chiusano (Logistics Management Institute). Posted to the OASIS ebXML Registry Technical Committee discussion list, apropos of the ebXML Registry Information Model V 3.0. Proposal: "A Namespace Manager function would allow a registry client to manage XML namespaces. This includes the ability to: (1) Associate constructs (elements, attributes, types) with a registered namespace: This would allow constructs used in XML Schemas or XML documents to be associated with their namespace within the registry. This functionality is necessary for the remaining three items that are listed. (2) Query on all constructs in a given namespace: Suppose a corporation's headquarters had a corporate-wide namespace; a branch operation may wish to declare an element as existing in their 'local' namespace (through the namespace functionality inherent with XML Schema), but do not want to do so if the corporate-wide namespace already contains the element. This query functionality would allow the branch operation to make this determination. (3) Perform a comparison between two or more namespaces: Keeping with the same general scenario, this functionality would allow a branch operation to report on (a) all constructs that were in their 'local' namespace but not in the corporate-wide namespace, or (b) all constructs that were in common between the two namespaces (i.e. perhaps unnecessary duplication), etc. (4) Perform life-cycle-type functions on a namespace (registration, deprecation, etc.): This would allow a registry user to enforce that any namespaces referenced in registered XML Schemas or XML documents must reference registered namespaces (if not, take some user-defined action such as error notification or automatic registration of a namespace). It would also allow a namespace to be retired..."

• [July 05, 2001] "XML Q&A: Namespace Nuances." By John E. Simpson. From XML.com. July 05, 2001. ['This month's Q&A column tackles the question of how to write DTDs for XML applications that use namespaces.'] "Namespaces enable you to mix, in one XML document, element (and sometimes attribute) names from more than one XML vocabulary... Once you start using namespaces in a particular document, you must commit to going the whole way. In theory, only the names of the two table element types needed to be disambiguated. In practice, though, you use namespaces to disambiguate entire vocabularies -- even the names of elements, like td and chair above, which are already unambiguous. Thus, if you decide to require that the furniture-type table have a furn: prefix, you're committed to using that prefix on the names of the furniture, chair, and lamp elements as well... Here's how the fragment of a DTD above, way back at the beginning, could be modified to accommodate both validation and namespaces. Now your application will find an element named f:deposit in the DTD, whereas before the DTD declared only an element named deposit (no prefix). And now the rest of the document can use any of the four explicit prefixes on any element name, as long as those names, including prefixes, are declared in the DTD. If an element named s:envelope appears in the document, an element named s:envelope must be declared in the DTD. A declaration for a simple envelope element won't suffice..." From Ron Bourret's FAQ: "DTDs can contain qualified names but XML namespace declarations do not apply to DTDs. This has a number of consequences. Because XML namespace declarations do not apply to DTDs: (1) There is no way to determine what XML namespace a prefix in a DTD points to. Which means... (2) Qualified names in a DTD cannot be mapped to universal names. Which means... (3) Element type and attribute declarations in a DTD are expressed in terms of qualified names, not universal names. Which means... (4) Validation cannot be redefined in terms of universal names as might be expected. This situation has caused numerous complaints but, as XML namespaces are already a recommendation, is unlikely to change. The long term solution to this problem is an XML schema language: all of the proposed XML schema languages provide a mechanism by which the local name in an element type or attribute declaration can be associated with an XML namespace. This makes it possible to redefine validity in terms of universal names..."

• [January 02, 2000] XML Namespace Resources. The end of calendar year 2000 saw eruption of (yet) another communal lament about the W3C XML Namespace specification, which fails to meet the expectations of some users. Resulting from the discussion: a number of new proposals for indicating "what a namespace URI should point to." (1) Tim Bray, one of the XML Namespace editors, licensed underground activity for a namespace markup vocabulary that could reference related resources ("it would have to be done low, fast, and under the radar...") and then floated his own suggestion for XNRL (XML Namespace Related-Resource Language). "XML Namespace Related-resource Language (XNRL) is an HTML-based markup language designed to contain a human-readable description of an XML namespace as well as pointers to multiple resources related to that namespace. Examples of such related resources include schemas, stylesheets, human-readable documentation (beyond that contained in the XNRL package) and executable code. XNRL is designed to be suitable for service as the body of a resource returned by deferencing a URI serving as an XML Namespace name. [The draft proposal] defines the syntax and semantics of XNRL, and also serves as an XNRL package for the namespace http://xnrl.org/." (2) Jonathan Borden presented an "XML Namespace Catalog Format." The proposal "defines a format for an XML Namespace Catalog. An XML Namespace Catalog serves as a text description of an XML Namespace and includes links to resources associated with the namespace such as schemata, stylesheets and/or other resources associated with the namespace URI. An XML Catalog may also map Formal Public Identifiers into System Identifiers defined as URI references. An XML Namespace Catalog is designed to be suitable for service as the body of a resource returned by deferencing a URI serving as an XML Namespace name. The XML Namespace Catalog format is an extension of XHTML with a new element named resource. The resource element serves as an XLink to the referenced resource. The resource element represents an XLink with two additional attributes public and content-type which provide for optional formal public identifiers and/or content type specifiers The proposal document defines the syntax and semantics of the XML Namespace Catalog Format, and also serves as an XML Catalog for the namespace http://www.openhealth.org/XMLCatalog. The XML Namespace Catalog 1.0 DTD has been produced as an extension of XHTML Basic 1.0." See also the example. (3) Sean B. Palmer presented XNCL (XML Namespace Catalogue Language) as just another hack attempt at producing an XML Namespace Catalogue Language that the people on XML-DEV will find solice in. XNCL is a language intended to be used as a de facto dereferencable resource for namespaces. XNCL uses empty div elements in the Link elements to avoid overloading them, and to allow for family derivations. The specification is an XHTML Family derived from XHTML Basic. It has been modified in the following ways: The content model for the link element has been changed so that it may now include div elements. An additional resource element may now be used inside link elements, and they are of content type EMPTY..." Note the posting from Paul Grosso on "resource discovery directory" which (1) references the work of the OASIS Entity Resolution TC, and (2) advocates a separation of concerns, viz., between ER (entity resolution) catalogs and resource discovery (RD) directories. See now: "Resource Directory Description Language (RDDL)."

• [August 13, 2001] "Opening Old Wounds. [XML Deviant.]" By Leigh Dodds. From XML.com. August 08, 2001. ['Dodds delves into namespaces again.'] " This week's XML-Deviant explores a namespace debate that has resurfaced on XML-DEV and wonders whether a few rays of sunshine could dry up this and other debates once and for all... The debate was sparked again following the publication of Simon St. Laurent's SAX Filters for Namespace Processing. These filters allow an explicit association of unprefixed child elements (e.g. familyName above) with a parent element's namespace. Some concern was voiced over the prospect of the side-effects of their unguarded use. But careful application of the filter could benefit those preferring to use explicit namespace associations..."

• [August 23, 2001] "A New Kind of Namespace. [XML-Deviant.]" By Edd Dumbill. From XML.com. August 22, 2001. "...when a technology emerges from the W3C there are always teething pains. W3C Recommendations aren't quite the shrink-wrapped parcels of authority they're often taken to be. Perhaps the canonical example of this has been the XML and Namespaces Recommendation, the somewhat unpredictable repercussions of which are still being felt; all the while, typically, the specification is heralded as a fine piece of work by some of its major supporters. This summer's problem child has undoubtedly been W3C XML Schema. One Schema issue in particular has already figured strongly in these pages: the use [of] unqualified elements within namespace-qualified types. Last week's discussion on XML-DEV, while not resolving this issue, has produced a useful crystallization of the motivation behind this technique. This article describes the motivation, the import of which seems to be that XML Schema has added to XML another form of namespaces... The inclusion of locally-scoped types in XML Schema is not an anomaly. It does come as a surprise, however, that it's taken this long to find a reasonable justification of the functionality... [thanks to a post from Matthew Fuchs] at least we know why locally scoped names were included in W3C XML Schema, something that will help the expert community develop best practices..."

• [May 07, 2001] "DTDs and Namespaces." By C. Michael Sperberg-McQueen. XML-DEV posting 2001年05月07日. "... It is certainly true that DTDs can contain sufficient information to support namespaces, in the sense that they can be used to define the names in a namespace, in a system which understands DTD notation and which can resolve qualified names correctly. But some outside system is required; no system which validates using a DTD and the validation rules of XML 1.0, without extension, can support all the syntactic variations allowed by the namespaces recommendation. When I say that DTDs cannot 'support' namespaces I mean simply that given some plausible account of the rules which govern elements in some set of namespaces, and the rules of the namespace recommendation (which include the ability to bind arbitrary prefixes to arbitrary namespaces), it is not possible to write a DTD which (using the normal rules of DTD-based validation) recognizes the set of documents which follow the rules, and distinguishes them from documents which don't. It is possible, using clever parameter entity tricks, to allow the user to associate namespaces with arbitrary prefixes. This is a partial victory. In their full generality, however, the rules of the namespace recommendation allow homography: elements with different universal names (and thus potentially different declarations) can appear with the same prefix + colon + localname as their generic identifier... I continue to believe that the DTD notation does not support namespaces 'in their full generality'."

• [May 04, 2001] Proposed URN Namespace for Public Identifiers. A posting from Norman Walsh contains the text of an IETF Network Working Group Internet-Draft which the authors believe "resolves all outstanding issues with respect to the request for a 'publicid' NID." The draft A URN Namespace for Public Identifiers ('draft-urn-publicid-03, May 4, 2001) is authored by Norman Walsh (Sun Microsystems, Inc.), John Cowan (Reuters Health Information), and Paul Grosso (Arbortext, Inc.). The draft "describes a URN namespace that is designed to allow Public Identifiers to be expressed in URI syntax." From the document Introduction: "XML external entities have two identifiers: a system identifier and a public identifier. The system identifier is a URI, by definition, but the public identifier is simply a string. Historically, the system identifier of an external entity has been a local, or system-specific identifier while the public identifier has been a more global, persistent name. Unfortunately, public identifiers do not fit neatly into the existing web architecture because they are not legal URIs. Many new specifications (XSLT, XML Schema, etc.) have the implicit or explicit requirement that all external identifiers be URIs. The purpose of this namespace is to allow public identifiers to be encoded in URNs in a reliable, comparable way. This document describes a scheme for representing public identifiers as URNs by introducing a public identifier namespace, 'publicid'. This namespace specification is for a formal namespace." [Full context]

• [January 16, 2001] A URN Namespace for Norman Walsh. Network Working Group, Internet Draft 'draft-nwalsh-urn-ndw-01'. By Norman Walsh, URI: http://nwalsh.com/~ndw/. July 2000. 5 pages. Abstract: "This document describes a URN namespace that is engineered by Norman Walsh for naming personal resources such as XML Schema Namespaces, Schemas, Stylesheets, and other documents." Description: "For some years, the author has been producing internet resources: documents, schemas, stylesheets, etc. In addition to providing URLs for these resources, the author wishes to provide location-independent names. In the past, this has been accomplised with Formal Public Identifiers (FPIs). FPIs provided the author with a mechanism for assigning unique, permanent location-independent names to resources. The Extensible Markup Language (XML) requires that all resources provide a system identifier which must be a URI and XML Namespaces require authors to identify namespaces by URI alone (it is not possible to provide an FPI for an XML Namespace identifier). Motivated by these observations, the author would like to assign URNs to some resources in order to retain unique, permanent location-independent names for them. This namespace specification is for a formal namespace..." [cache]

• [May 05, 2001] "Transforming XML: Namespaces and Stylesheet Logic." By Bob DuCharme. From XML.com. May 02, 2001. ['In the second part of a two-part series on handling XML Namespaces, Bob explains how to process namespaces in a source document, and gives an example of processing XLink into HTML.'] "In last month's 'Transforming XML' column, we saw how to control the namespaces that are declared and referenced in your result document. If your stylesheet needs to know details about which namespaces are used in your source document, and to perform tasks based on which namespaces certain elements or attributes belong to, XSLT offers a variety of ways to find out. This month we look at them. To experiment, we'll use the following document. It has one title element and one verse element from the http://www.snee.com/red namespace, two verse elements from the http://www.snee.com/blue namespace, and one verse element from the default namespace... XSLT's ability to base processing logic on namespace values makes it a great tool for developing XLink applications. As you use XSLT to process more and more XML documents with elements from specialized namespaces -- for example, SOAP envelopes, XHTML elements, or XSL formatting objects -- you'll find these techniques invaluable for keeping track of which elements come from where so that you can take the appropriate action with them." [Sample documents and stylesheets are available in the zip file.]

• [October 02, 2000] "Exposing Namespaces in Instance Documents." By Roger L. Costello (et al.)

• [August 15, 2000] XSet: An XML Property Set Description of XML 1.0 and XML Namespaces. Jonathan Borden (The Open Healthcare Group) has announced the availability of a short working description of an 'XSet' XML EBNF property set description. Background: "ISO Groves and Property Sets are a formal mechanism to unify the addressing schemes of HyTime and DSSSL. Groves allow addressing and linking into multimedia formats which have defined Property Sets: essentially a 'grand unified theory' of addressing. In practice, EBNF grammars are widely used to specify formats including XML, MIME, URIs etc. The XSet production language is proposed as an alternative to ISO Groves to enable grove based processing of formats defined in EBNF." Description: "XSet is an XML property set description of XML 1.0 and XML namespaces. The description is a result of translating the Extended Backus-Naur Form (EBNF) productions into an XML language: the production rule langage (PRL). XSet xml.xml is an RDF description of the productions in XML 1.0 and XML Namespaces. RDF is used to provide metadata about the production set, including that it is 'about' XML 1.0 and 'about' XML Namespaces. RDF adds very little overhead to the property set which is itself a compact description. XSet enables XPath based indexing and addressing of the full fidelity grove of an XML document. Bonsai is a pruning and compression diagram which maps the full XSet specification onto a subset or grove plan. Examples of XSet bonsai are (1) the XML Infoset, (2) the XPath data model, (3) the DOM data model, (4) Common XML and (5) Eric van der Vlist's technique of exposing entities through the SAX model." Jonathan also writes: "On the topic of using XSLT to transform RDF<->Infoset, Dan Conolly has posted links to a couple of nice XSLTs at http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0061.html. . . Eric van der Vlist and I have been having an offline discussion about the similarities between his technique of using a special SAX parser to 'expand' entity declarations into 'Common XML' content. The advantage of this approach is that XPath and XSLT can be used to process the resultant abstract document (which in his example preserves the entity reference). This is very similar to the approach of XSet which logically 'expands' an XML document into a full-fidelity grove. . . A goal is to provide an XSet 'bonsai' or pruning, twisting and compression document which directs the processor as to what level of detail to provide. For example: should it generate 'element' events alone, or add STag, ETag and EmptyElementTag events. XMTP [http://www.openhealth.org/documents/xmtp.htm] is an XSet expansion of a MIME document. In the same way that an XSet expansion of an XML document can be produced by a modified SAX parser, an XMTP expansion of a MIME message can be produced by a MIME parser which emits SAX events. This technique provides a general mechanism for XPath/XPointer addressing of, and XSLT transformation of arbitrary syntaxes expressable in EBNF. This is the essence of the grove paradigm." Dan Connolly's work was presented under the title "XML in RDF in XML via XSLT: An infoset implementation." One stylesheet 'content.xsl' "takes piece of XML content (i.e., stuff matching the content production, like you might find inside a parseType="literal" element in RDF) and represents it in RDF, per the schema in the infoset specification." Connolly will integrated this with the stylesheet rdfp.xsl (RDF parser in XSLT); "This highlights some of the differences between the infoset data model and the XPath data model, since I'm using XPath to destructure the input. I think it also clarifies some stuff about how [the attribute] xml:lang fits into the RDF model, and about how XML Schema datatypes (and structured types, for that matter) fit with RDF..." For other background, see "Groves, Grove Plans, and Property Sets in SGML/XML/DSSSL/HyTime."

• [July 10, 2001] "Clean XML Namespacing Pattern." By Tom Bradford. Last revision: July 10, 2001. "This document presents a pattern for clean namespace representation in XML 1.0. It is not meant to be a specification that would require additional APIs, and it is not meant to replace formal namespaces. The objective is to define a simple way to non-invasively represent XML namespaces with simple qualified naming patterns... Because formal namespaces break XML 1.0, introduce serious usability issues, and require layering support over existing APIs which introduces considerable overhead. Clean namespaces could be used with DOM 1 and SAX 1 without introducing extensions for namespace support. The use of clean namespaces could also reduce the need for formal namespace features from more recent API versions, which may result in performance benefits, depending on the implementation. Clean namespaces could also be used in DTD definitions, which are traditionally problematic when it comes to formal namespaces. As DTDs were defined with XML 1.0, when formal namespaces didn't exist, they suffer from the same resolution problems that any other pure XML 1.0 application would face when dealing with formal namespaces..." [cache]

• [April 06, 2001] "Transforming XML: Namespaces and XSLT Stylesheets." By Bob DuCharme. From XML.com. April 04, 2001. ['A guide to using XSLT to create documents that use XML Namespaces.'] "In XML a namespace is a collection of names used for elements and attributes. A URI (usually, a URL) is used to identify a particular collection of names. Instead of including the URI with every element to show which namespace it came from, it's more convenient to name a short abbreviation when a namespace is declared and to then use that abbreviation to identify an element or attribute's namespace. Many simple XML applications never need to declare and use namespaces. If they don't, the XML processor treats all elements and attributes as being in the default namespace. This may be the case with some of your source documents, but it's certainly not the case with your XSLT stylesheets: the declaring and referencing of the XSLT namespace is how we tell an XSLT processor which elements and attributes in a stylesheet to treat as XSLT instructions... In this column, we've seen how to control the namespaces that are declared and referenced in your result document. Next month, we'll see how your XSLT stylesheet can check which namespaces are used in your source document and perform tasks based on which namespace each element belongs to."

• [September 15, 2000] W3C XML Plenary Decision on Relative URI References In Namespace Declarations. Dan Connolly (W3C) announced the W3C's decision on the matter of relative URI references. The decision and rationale are provided in a W3C document Results of W3C XML Plenary. Ballot on relative URI References in namespace declarations. [3-17 July 2000]. "By a large margin, the XML Plenary endorses the proposal given below. A number of organizations (both some those who find the proposal acceptable and some of those voting otherwise) believe that the W3C should proceed to develop a longer-term solution by means of the normal WG process. Proposal: "to deprecate the use of relative URI references in namespace declarations; that is: to say that while they conform to the Namespace Recommendation of January 1999, later specifications such as DOM, XPath, etc. will define no interpretation for them." See the document for examples of deprecated usages of relative URI references in namespace declarations. [cache]

• [March 10, 2000] "Namespace Myths Exploded." By Ronald Bourret. From XML.com. March 06, 2000. ['Published over a year ago, the "Namespaces in XML" recommendation may only be a small specification, but it's caused more than its fair share of confusion.'] "The XML namespaces recommendation is tantalizingly vague about, or omits altogether, a number of apparently important points. In practice, this is not a problem -- the points are not actually important and the recommendation does what it was designed to do: provide a two-part naming system for element types and attributes. Thus, as long as you don't look too deeply, XML namespaces do their job and do it reasonably well. Of course, many people have looked too deeply. Programmers are curious people and the close link between traditional namespaces and identifiers, as well as the perceived link between XML namespaces and schemas, has naturally invited closer inspection. So too has the fact that the XML namespaces recommendation introduces a new naming system, but does not discuss validation or how to declare XML namespaces in DTDs. Equally inviting is the fact that it discusses the structure of XML namespaces, but in a non-normative appendix. The result has been confusion and controversy. This article discusses a number of myths that have arisen around XML namespaces, examining possible sources, clarifying what the recommendation says about them, and pointing out ways to resolve the issues they raise. It is hoped that this will help clear up some of the confusion about XML namespaces, as well as reinforcing the point that most of that confusion revolves around things not required to use XML namespaces as they were designed -- that is, as a two-part naming system for element types and attributes."

• [January 07, 2000] "Here are the tricky points about Namespaces: (1) Namespace URIs are just unique identifiers, like Java or Perl package names; they don't (necessarily) point to anything. (2) There can be a default Namespace for element names but not for attribute names. (3) Not withstanding #2, some apps may treat unprefixed attribute names as if they belong to the same Namespace as the corresponding element name. [...] If you want to run through a quick Q-and-A to make sure you've got it, take a look at the following: http://www.megginson.com/docs/namespaces/namespace-questions.html. Sure, the stuff about per-element Namespace partitions and global attributes is confusing, but it's non-normative and you can safely ignore it. (David Megginson. XML-DEV, 2000年01月07日)

• [October 26, 1999] "URIs for W3C Namespaces." Tim Berners-Lee (and others). The document at this URI was published for citation in public forums for the purpose of discussion. See Section 5.1 'Background' for earlier discussion documents, and the public discussion list with postings beginning in 1994. Excerpts: Namespace URIs in Recommendation Track documents shall start with http://www.w3.org/ followed by four decimal digits corresponding to the common era year of issue. A group MAY request a specific path component for the rest of the URI, but the Webmaster has final authority over it. Groups SHOULD use namespace URIs that have the characteristics of uniqueness... The W3C Webmaster allocates all namespace URIs. Director approval of a namespace URI is NOT REQUIRED when it has the form http://www.w3.org/YYYY/MM/ssss, where ssss is a short string not causing confusion, alarm, or embarrassment... In all Member and Team Submissions, namespace URIs MUST be dereferenceable, and Namespace Documents must describe the relationship between the defining specification and the Namespace URI When a Submission is designed to seed work on the Recommendation Track, Namespace URIs SHOULD follow the conventions for Recommendation Track documents in order to ease the later transition to the Rec Track. If it does not, the URI publisher MUST have clear persistence policy similar to W3C's, i.e., that the URI publisher will make every effort to service requests for the Namespace Document... It is important to specify clearly the relationship between the Namespace URI and the specification that defines it. Groups SHOULD explain that relationship in the defining specification and/or schema. To this end, Groups SHOULD use this template... A Namespace Document describes the namespace, providing directly or by reference information for human and also, ideally, machine consumption. A Namespace Document is available for retrieval using a corresponding Namespace URI. When a Namespace URI appears in a Recommendation Track document, the responsible group MUST publish a corresponding Namespace Document. In other contexts as well, groups SHOULD publish Namespace Documents. RDFS and/or OWL are used for RDF namespaces..."

• See also the corresponding press release; [local archive copy].

• [February 02, 1999] James Clark has written a document "XML Namespaces" which "tries to explain the mechanism specified by the W3C XML Namespaces Recommendation. It explains things in a somewhat different way which [Clark] hopes at least some people may find less confusing than the explanation in the Recommendation."

• [February 08, 1999] "19 Short Questions about Namespaces (With Answers)." By David Megginson. Monday 8 February 1999 (v.2) or later. This brief review [of XML Namespaces] uses James Clark's notation for writing names that contain both a URI part and a local part. See also the copy posted to XML-DEV, 1999年02月08日.

• [February 02, 1999] The XML Namespace Spec - Summarized by Tim Bray. [Note: Tim is authoring an 'annotated' version of the W3C Recommendation, which will serve as a commentary.]

• [January 20, 1999] "XML Namespaces by Example." By Tim Bray. From XML.com (January 19, 1999). "January 14th [1999] saw the arrival of a new W3C Recommendation, Namespaces in XML. 'Recommendation' is the final step in the W3C process; the status means that the document is done, frozen, agreed-upon and official. Namespaces are a simple and straightforward way to distinguish names used in XML documents, no matter where they come from. However, the concepts are a bit abstract, and this specification has been causing some mental indigestion among those who read it. The best way to understand namespaces, as with many other things on the Web, is by example." See also the W3C Recommendation.

• [January 14, 1999] "Namespaces in XML" - A W3C Recommendation. References: REC-xml-names-19990114, World Wide Web Consortium 14-January-1999. [local archive copy]

• [September 16, 1998] "Namespaces in XML." WD-xml-names-19980916, World Wide Web Consortium Working Draft 16-September-1998. [local archive copy]

• [August 04, 1998] James Clark on a Java implementation of the Namespace Draft, WD-xml-names-19980802 - "At first glance the new namespace draft might appear rather complicated, but actually it is really easy to implement . . . here's all it takes to implement basic namespace processing in Java. . ."

• [August 02, 1998] Namespaces in XML. WD-xml-names-19980802. [local archive copy, HTML, local archive copy, XML]

• [May 18, 1998] Working Draft 18-May-1998 in HTML format; also in XML format; [local archive copy, HTML; local archive copy, XML]

• [March 27, 1998] Working Draft version March 27, 1998.

• [February 10, 1998] "Web Architecture: Extensible Languages." W3C Note 10 Feb 1998. NOTE-webarch-extlang. By Tim Berners-Lee and Dan Connolly (W3C). "This document is meant to be a fairly explanatory synthesis of the requirements for namespace extension in languages on the web, and in particular for the general language planned to be the common basis of many future applications, XML. It was originally written as part of the 'Design Issues' series of notes. Whilst technically the personal opinion of the authors, it their best attempt as technical coordinators at outlining common architectural principles for W3C development." [local archive copy]

• NOTE-xml-names in HTML format from W3C; [local archive copy]

• NOTE-xml-names in XML format from W3C; [local archive copy]

Document URI: http://xml.coverpages.org/namespaces.html — Legal stuff
Robin Cover, Editor: robin@oasis-open.org