Namespace Applications

[james anderson]

Paul Prescod wrote:
> 
> David Megginson wrote:
> > <email>paul at prescod.net</email>
> > <company>ISOGEN</company>
> > <a:origin>Canada</a:origin>
> > <b:origin>University of Waterloo</b:origin>
> > </member>
> >
> > ...
> >
> > The advantages of being able to come up with globally-unique names
> > should be obvious:
> 
> Actually it isn't to me. The problem is now you have <a:origin> and
> <b:origin> element types but you don't know what to do with them. This is
> the point I keep harping about: processing expectations.

So long as one remains in the "encoded XML" domain, the names are (modulo
validation) academic. XML is one thing, and one thing only: a *code* - that is
a specified collection of symbols with a collection of permitted relations.
Which means that there is no semantics to be concerned with. There should be
no exectation that namespaces change that.

A semantics appears exactly at the point where the relation to the source
and/or target domain is specified. Which cannot happen in the code itself. It
happens at the point where a document becomes an *encoding* of something else.
At this point  one *does* know "what to do with them" because the domain to
which one is decoding includes a process specification, or constraints on
values, or whatever. At which point the question becomes "is the encoding
complete and consistent?" At which point unambiguous names are essential.

The essential requirement is not that of correct names. (cf. the
<david:CountryOfOrigin> point below.) Neither is it that of correct relations.
(cf. the XSL/ EA point below). It is that of unambiguous names.

>          Clearly
> <a:origin> is supposed to be mapped either to nothing or to
> <david:CountryOfOrigin> and <b:origin> is to be mapped either to nothing
> or to <david:GraduatedFrom>. It seems to me that information should not be
> let into my information system until it is expressed in terms that my
> information system is familiar with.

Iff an application has a "{a=}origin", it can determine that the intended
treatment is that of "{david}CountryOfOrigin".

"XML Namespaces" permit the application to delay until the point of decoding
the binding of an encoded name to a symbol in the application domain. Iff this
is possible, then a *direct mapping* to the application domain is possible.
Which is why similar facilities must be supported within enabling
architectures, which interpose additional encodings as proxies for the
eventual application domain.

> 
> What that means is that these things should be shipped with either
> architectural declarations or an XSL stylesheet that lets me locally
> reinterpret them.

Iff there is a mismatch between the immediate decoded domain and the eventual
application domain, then there is more to do. I suggest, however, that this is
not intrinsically a decoding problem and, as such, has only indirectly to do
with namespaces. As noted, it can be handled with mechanisms such as those
provided by XSL or enabling architectures, but need not be. Note also, that to
literally "ship" documents with a stylesheet begs the question. The eventual
binding is to be specified by the receiving process, not the sending process.
To augment them at the receiving end is a possibility, but overlooks that
there are alternative application mechanisms to do much of that for which one
would use architectural forms or XSL transformations.

In cases where the application environment does not provide the necessary
mechanisms, I'd put my money on XSL, as it supports more extensive
transformations than enabling architectures. The combination (namespaces +
XSL) also provides a better separation of the two mechanisms. The combination
is unavoidable. Unless one is willing to express all XSL patterns in a context
dependant form, then unambiguous names remain a requirement and some sort of
namespace mechanism is a prerequisite to guaranteed matches. If one is willing
to limit patterns to context dependent expressions and to presume complete
documents as reference targets, then one would succeed at pushing the problem
back to that of ensuring "unique document type names".


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)