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

SD5 - Namespaces [fmt]

From: Jon Bosak <bosak@atlantic-83.Eng.Sun.COM>
Date: Fri, 16 May 1997 13:52:52 -0700
Message-Id: <199705162052.NAA15728@boethius.eng.sun.com>
To: w3c-sgml-wg@w3.org
 From: Jean Paoli <jeanpa@microsoft.com>
 To: "'w3c-sgml-wg@w3.org'" <w3c-sgml-wg@w3.org>
 Subject: SD5 - Namespaces
 Date: Thu, 15 May 1997 21:14:20 -0700

 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

 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.

 Proposal: Every element comes from some schema, which becomes the
 default schema for that element. The names within the default schema
 are usable within the element without qualification. Names from other
 schemata are also usable (provided they are compatible with the
 elements definition) but must always be qualified.

 Every element can have one or more foreign schemata introduced to it
 by a well-known attribute which refers to a schema by URI, and gives
 it a short name used for qualification.

	 <*xml-schema xml-ref="http://www.bigbookstore.com/schema"
 xml-as="bk" />
	 <*xml-schema xml-ref="http://www.w3.org" xml-as="org.w3.www" />
		 <*xml-schema xml-ref="http://purl.org/dublincore"
 xml-as="dc" />
		 <*xml-schema xml-ref="http://www.shipping.com"
 xml-as="sh" />
			 <dc.NAME>Number, the Language of


 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.

Received on Friday, 16 May 1997 16:53:24 UTC

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