W3C home > Mailing lists > Public > xml-names-editor@w3.org > December 2004

A proposal for namespace definition to parallel namespace declara tion

From: Vun Kannon, David <dvunkannon@kpmg.com>
Date: Tue, 7 Dec 2004 14:11:51 -0500
Message-ID: <E572FF4B5534D21182E300805FA7436225E06531@usnssexc05.us.kworld.kpmg.com>
To: "'xml-names-editor@w3.org'" <xml-names-editor@w3.org>
Cc: "'XBRL-SpecV2@yahoogroups.com'" <XBRL-SpecV2@yahoogroups.com>

Sirs,

It has always appeared to me that namespaces are a general feature of XML,
and that "XML Schema element and attribute names" is just one way to
implement a namespace. However, this example of  namespace implementation
has historically been the only way to define a namespace in practice.

Consider the namespace of ISO 4217 monetary designators. This is a well
known collection with members like EUR, USD and JPY. Many XML languages
would like to use QNames in element or attribute content, such as
currency="iso4217:USD", and have some enforcement mechanism that that name
really is a member of that namespace. The current limit of quality control
is to check that the namespace prefix is properly in scope. This is
inadequate.

I propose to you that the XML Namespaces work stream should undertake the
following:

	 - define the possible contents of a namespace, for example as a
node list of unique Names
	 - be explicit that the set of names of elements and attributes in
an XML Schema is just one way of implementing a namespace
	 - provide a mechanism to define the members of a namespace, if the
namespace is not implemented as a schema

As an example of the last item, XML Namespaces could rule that the namespace
"xmlnsdef" is to be used for namespace definitions of the form

	xmlnsdef:nsprefix="IRI that ends in an XPath expression to select a
unique set of nodes"

In the ISO 4217 case, imagine that the 4217 maintenance agency maintained an
XML document that looked like

<iso4217>
	<currency designator="USD" name="Dollar" issuer="United States"/>
	<currency designator="EUR" name="Euro" issuer="European Union"/>
	<currency designator="JPY" name="Yen" issuer="Japan"/>
</iso4217>

In a use of this file

<inventory
	xmlns:iso4217="http://maintenance.iso.org/4217"
	
xmlnsdef:iso4217="http://maintenance.iso.org/4217/iso4217.xml#xpointer('/cur
rency/@designator')"
>
	<sku id="sku6" units="2000" cost="12.37"
purchased_currency="iso4217:USD" purchase_date="2001-10-27"/>
</inventory>

The declaration and definition of the namespace are paired in such a way
that violations of the namespace are easy to catch.

It is also possible to allow intrinsic as well as extrinsic definitions of
namespace, if the fragment syntax is replaced with a query syntax.

It can always be argued that any namespace can be expressed as an XML schema
somehow, so why bother? The answer is that we cannot rely on namespace
owners to "do the right thing" when the result is arbirtrary, artificial,
difficult for them to maintain, or simply no longer an option.

I apologize if similar ideas have already been discussed and decided
against. As a participant in the design of XBRL (eXtensible Business
Reporting Language) it has been my experience that a facility such this
proposal would be a very useful addition to XML Namespaces. QName content is
no longer identified with element and attribute names and this should be
recognized and supported within XML Namespaces.

Sincerely,
David vun Kannon




*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************
Received on Tuesday, 7 December 2004 19:12:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:44 GMT