Re: HL7-v3-XML namespaces

On 1/13/09 2:35 PM, "Michael Kay" <mike@saxonica.com> wrote:

> In my view it makes sense to associate a namespace one-to-one with a
> specification document that describes and defines the meanings of the names
> in that namespace. It really doesn't matter whether these names are used in
> a single type of document or message, or in 400 different types of message.
> If it makes sense to define the messages in a single spec, then it also
> makes sense to use a single namespace.

I almost completely agree with Mike, except that there may a many-to-one
specification-to-namespace relationship, meaning that a given specification
(standard) may define multiple namespaces, but a given namespace should be
defined in exactly one specification (that is, two specifications should not
be defining elements in a given namespace).

It's also important to remember that schemas govern *elements*, not
documents. In fact, despite the misleading name "document type", XML (and
SGML before it) never has had a very useful notion of "document type" in the
sense of defining "Document" as a business object type that has well-defined
rules associated with it, beyond the simple syntactic rules of XML document
instances.

With DTDs, any element declared in the declaration set (including those
declared in an internal declaration set) can be the root element (the
"document type") and there's no standard-defined way to limit that.

With XSD schemas, any global element type may be the root of a document, but
even in the case where a schema declared exactly one global element, that
element need not be the root element of documents that contain it.

With namespace-governing schemas, the schema is bound to a namespace, which
in turn is a property of *elements*. A given document may have any number of
schemas associated with it, one for each different namespace used in the
document.

The only thing that matters is elements and their names, really.

I find it useful to have different namespaces for different areas of
*concern* where there might be different combinations of concerns in a
single set of related elements.

Note that having multiple XSD schema documents that all govern the same
namespace but contribute different sets of element declarations leads to a
number of practical problems (not least of which is determining by
inspection which one is the "root" schema), so I find that anything that
would naturally be a module of a schema tends to want to be in a distinct
namespace so that there is exactly one schema XSD document for that set of
elements. 

Note that having different schemas for the same namespace, where each
different schema declares *all* the elements in the namespace, is different
from having a single *effective* schema composed of multiple documents.

There are compelling and unavoidable reasons to have variant schemas for the
same namespace, but in that case there's no reasonable expectation that the
correct schema to use for a given purpose can be determined without some
sort of out-of-band information (e.g., "this one is for authoring, this one
is for archiving, this one is for validation of modular documents").

By contrast, given a namespace and a set of single-document schemas, one can
easily determine which schemas *may* govern the namespace, and in the case
where you find at most one, there is no ambiguity about that schema being
the right one to use.

Cheers,

Eliot

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>

Received on Tuesday, 13 January 2009 21:00:50 UTC