namespaces and document structure [Re: Next Round]

james anderson James.Anderson at
Mon Jan 25 15:08:51 GMT 1999

Tyler Baker wrote:
> james anderson wrote:
> > ...
> >
> > (When I hear of application which process *prefixes* I'll take this back.)
> You may have content which is processed by multiple applications, some of which are
> namespace aware and some which are not.  Some applications may want to do their own
> namespace processing and will want to know the exact document structure of the original
> document.  Hey, when I hear of an application which actually uses "Namespaces in XML" I'll
> take a lot of things back.  It would be nice if some developers here could post examples of
> successful uses of "Namespaces in XML" so we have some sort of context to move forward with
> intregating "Namespaces in XML" into SAX.

We have a rather large application which uses XML as the encoding for data
exchange between a mid-tier server and java-base ui-frontends. In itself
that's nothing special. There is, however, one aspect which has a bearing on
this discussion. The mid-tier-animal is implemented in lisp. Which means that
symbols abound. Which means that the efficiency and clarity of the
implemention benefits extrordinarily from unambiguous names. Which means it
has depended on a "namespace substrate" since before XML was a PR.
> ...
> Plain and simple, each Name belongs to a particular namespace at a given point in time.  The
> prefix meanings may be volatile, but for applications which want to know "exactly" what the
> text of the original document looked like (for example editors), I think exposing namespace
> prefixes, or at a minimum the qualified name would be a good thing.

This passage is unclear. The concept "Name" was supplanted in the ns-spec with either
1. "NCName" for that case where either the generic name for a "Prefix" or a
"LocalPart" is intended, or
2. "QName" for the case where a "Name" is encoded in a document, or
3. an "universal name", the scope of which "extends beyond the document".

It is not clear which of these is the intended meaning of "Name" in the
passage above. In any event
1. a "NCName" cannot belong to a namespace. It may be the "LocalPart" of a
qualified name - which may be among the names comprised by a namespace
2. a "QName" also does not belong to a namespace, it merely encodes a mapping
to a universal name, but does so under specific conditions only
3. an "universal name" is comprised by (or interned in) a namespace, and meets
this condition without temporal or lexical restriction. The relation to a
content model and or attribute declaration <em>may</em> be restricted.

As to the editor question: the application noted includes no code outside of
the parser which references a prefix. That's because no application need pay
attention to the prefixes which were in effect at the time a universal name
was decoded. An application need pay attention to URI's only. In the case of
lisp, the application need not pay direct attention to them either, as the
lisp reader implements rules analogous to namespace when it parses, so the
symbols are simply identical.

If one desires, for legibility or vanity reasons, to specify or present a
prefix, this can be performed reliably with reference to elements only - not
with reference to names, and only as a side-effect of the relation between the
name, the URI of the comprising namespace, and a prefix binding effected by
the element. If the application is an XML editor, it will not be permitted the
luxury of presuming that the prefix which was in effect when an element was
decoded is the correct prefix at the point in time where a name is encoded -
whether for view, for interpretetation, or for transmission. If it does make
this presumption, then it will not be a very powerful editor. 

That is to say, in the presence of namspeaces, there is no canonical encoding.
One can make believe, but the effect won't carry very far.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list