Clean XML Namespacing Pattern Tom Bradford Last revision: July 10, 2001 From: http://www.tbradford.org/clean-namespaces.txt Please report my terrible English to bradford@apache.org Introduction ------------ 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. Definitions ----------- Formal Namespaces refers to the W3C Namespaces specification. This specification is disruptive to XML application development because it introduces inconsistencies in the interpretation of XML 1.0 documents that can only be resolved by namespace-aware tools. More information on this specification can be found at: http://www.w3.org/TR/1999/REC-xml-names-19990114/ Clean Namespaces refers to the namespace pattern being discussed in this document. Background ---------- It has been said that terseness is not what XML is about, yet the formal namespace specification uses document-anchored prefixes that map to unique namespace URIs as a space-saving mechanism. Additionally, the idea of default namespaces is also part of formal namespaces, which eliminates a prefix altogether for a set of descendants. This is problematic when developing applications from a pure XML 1.0 standpoint, where the concept of formal namespaces doesn't exist, or where unnecessary processing overhead is something to be avoided. Why? ---- 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. For an example of the joys of mixing and matching DTDs and formal namespaces, see: http://www.xml.com/pub/a/2001/07/05/namespaces.html Processing Instruction ---------------------- A processing instruction named 'ns' can be included in the document to hint to the parser that namespace prefixes in this document may be based on the clean namespace pattern in addition to formal namespaces. Example: Qualified Name -------------- A qualified name is an element or attribute name that includes a namespace prefix followed by a colon (:) and a scoped element or attribute name. Examples: org.dbxml.cfg:system xlink:href Namespace Prefix ---------------- A namespace prefix is a unique qualifier that identifies the scoped element or attribute as belonging to the defined namespace. Namespace prefixes must minimally include a top-level domain name in the Java package naming convention with at least two name components (ex: org.dbxml). The W3C reserves ALL single component names for XML extensions (such as XLink and Schemas). The choice behind using the Java package format is simple, it's more straight-forward to visibly sort a taxonomy when the highest order component is the first token present. Examples: org.dbxml.obj xlink Absence of a Prefix ------------------- Elements and attributes may be defined without prefixes, but their meaning is different. Elements without a prefix are considered to be in the 'nil namespace'. The nil namespace is provided for applications under tight control, where namespace support isn't required, or where its use is very predictable. Attributes without a prefix are considered to be 'tied'. Tied attributes are assumed to be part of the namespace of their owner element, and shouldn't include a namespace prefix. An element may also contain namespaced attributes (XLinks for example) if those attributes belong to a namespace other than the element. Example: ... Cohabitation ------------ Clean namespaces can exist with formal namespaces. In the case where a document includes both, it should be assumed that the parser will identify xmlns attributes and properly create formal namespace contexts for those definitions. In those cases, the developer can use extended DOM and SAX methods for formal namespaces as they normally would. Cohabitation may present problems with existing tool sets. For example, most XPath implementations require a context node in order to resolve prefixes to formal namespace URIs. Whether or not these tools continue to behave properly when a URI mapping is not present depends on the implementation. Interoperability ---------------- At the XML tool author's discretion, they may choose to expose clean namespaces to the API as though they were formal namespaces. The rules for doing this involve reversing the order of the name components in the prefix, and prepending http:// to it in order to generate a URI for the specified prefix. This is not a strict requirement of clean namespaces, and is only proposed as a means of consistency for applications that are already fully entrenched in formal namespace operations. Example: The URI for org.dbxml.cfg Would be http://cfg.dbxml.org Example Document ---------------- Bradford, Thomas 1 (480) 123-1234 Mesa Arizona Nothing much to say