W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > May 1997

SD5 - Namespaces - New Version 2

From: Andrew Layman <andrewl@microsoft.com>
Date: Thu, 22 May 1997 18:35:59 -0700
Message-ID: <7BB61B44F197D011892800805FD4F792A4BFD8@RED-03-MSG.dns.microsoft.com>
To: w3c-sgml-wg@w3.org
I have modified the proposal somewhat to take into account the
discussion of
the last week. Please read this in conjunction with my several recent
justifying some of the decisions.

SD5 - Namespaces:

 Consumers of a document may need to verify that it uses a known
 namespace. For example, the document may declare, in effect, "This is
 an OSF banking document.  If you know what that means, this is
 confirmation you have the right document type." We need a mechanism
 for identifying schemata so readers of a document can tell what the
 element names mean. At the same time, the namespace of schema ids must
 be open and unlimitedly extensible, without requiring any central
 naming authority (beyond whatever mechanisms already exist for the

The identity of a namespace is independent of the document (if any)
its terms. That is, a namespace does not equal a DTD. Namespaces are 
simply unique name domains.

 Additionally, we want to make it common that documents incorporate
 elements and attributes from multiple schemata. For instance, within a
 document about book orders, we might reasonably find elements such as
 "author" defined by the Dublin Core, other elements such as "price"
 that are particular to the book order application, and still other
 elements, such as digital signatures, common to many
 applications. (One advantage of common terms is that we can pass
 elements across organizational boundaries.)

 However, there is a problem with including names from multiple
 schemata: common, easily understood terms such as "name," "type,"
 "size," "location" etc.  are likely to be defined in many
 schemata. While each definition makes sense in the context of the
 defining schema, when a document uses several schemata the names will
 clash (if not initially, then as schemata evolve). We need a mechanism
 for avoiding such conflicts. Within every portion of a document, it
 must be unambiguous from which namespace each name originates.

Subelements (or attributes) from different namespaces will be used
a single parent element. Authors need to be able to mix such subelements
without modifying any DTDs. In fact, as stated above, the solution 
for namespaces should not presume the existence of DTDs. 

URIs are excellent identifiers for namespaces in all regards except two:
They are lengthy and they contain illegal characters. The latter is the


 The colon (":") character is now a legal character in names.

 A name containing a colon is to be interpreted as having two parts,
 where the part preceding the colon is the name of a namespace.
 That is, the namespace qualifies the element name.

 All names are interpreted as having qualification, but the
 can be syntactically omitted when the name comes from the same
 space as the immediately enclosing element.

 Any element can have one or more foreign namespaces introduced to it.
 This is effected by a well-known subelement ("xml-namespace") which 
 refers to a namespace  by URI, and gives it a short name used for
 Names used within  the element use the short name as their qualifier. 
 The short name serves to reference the full name of the namespace,
which is the URI.





			 <dc:NAME>Number, the Language of
			 <w3:DSIG> <DIGEST>1234567890</DIGEST>


 In the example above, bk:ORDERS comes from the bigbookstore schema.
 Consequently, terms such as lineitem and price, presumably defined in
 that schema, do not need qualification when used within
 bk:ORDERS. However, the terms NAME and AUTHOR are drawn from a schema
 transcending bookstores; they come from the Dublin Core document
 identified by the URI "http://purl.org/dublincore".  Similarly, the
 DSIG element is defined within the "http://www.w3.org" schema.

 The grove simply reproduces the element structure as though there were
 special about the XML-NAMESPACE element or the qualified names. It is 
 processors of the grove who worry about interpreting the qualified

--Andrew Layman
Received on Thursday, 22 May 1997 21:36:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:26 UTC