Asking the right questions: namespace documents

I'm not interested in prelonging a debate -- I believe the
wrong issus are being debated, and, as a consequence,
people are getting a little confused.  We have to solve
the right problem.  If we do so, it turns out that issues
like how to deal with identity of URIs become a non-problem.

As I understand it, we have the following situation:
(1) XML documents can use a disambiguating prefix in order to
    associate specific semantics with particular elements.
    For example, if I want to use the HTML "A" element, I might
    use a prefix of w3, and write
	<w3:a href="x.xml">this</w3:a>
	<w3:a w3:href="x.xml">this</w3:a>.

(2) The prefix has meaning only within a single document.
    No XML processor is supposed to recognise my "w3" prefix.
    I could equally well use "www", "v6", "html", "tbl" or anything
    else I wanted.

(3) The prefixed elements are associated with externally defined
    behaviour. This association is accomplished in an unspecified
    way [see below] using an "xmlns:" attribute:
    <document xmlns:w3c="">

(4) It is possible to use a Schema or DTD to validate a specific,
    static use of namespaces:
	<!ELEMENT document
    This is important: namespaces do not prevent validation, although
    many uses of namespaces make validation difficult.

I said that the mapping was accomplished in an unspecified way.

You might expect that following the URI given in a namespace
would lead to a document that said
    the A element does linking, it's really cool and will change the world
    the I element contains the ISBN of a book, which can be looked
    up in a database to obtain the book's title and price.

The state of computer programming is such that it's not possible
(as Alan Kay once suggested [1]) to describe this behaviour using
computer code.  A java applet could do one or the other in some
environments, and JavaScript could implement the "A" element, but
in truth today, an XML client (whether it's a web browser or a
speradsheet or a fault tolerant monitoring system) can really
only reliably use behaviour that is already programmed into it.

Applets are limited to Java-awaer systems (not yet a clear majority
on the Internet today as HTML browsers after five years).

ActiveX is platform and vendor specific, and JavaScript is limited
in functionality.

The SGML world tried going down the route of formal public identifiers
to identify behaviour, but this just gives you a label, and does not
address the underlying issue.

If we had solved the hard problems, the XML processor would
read the resource pointed to by the xmlns attribute, interpret it,
and use it to decide what functionality to enable.

Probably this document would also contain a pointer to a schema to
validate each namespace used, and might itself refer to external

Right now, we have not solved that problem.

I suggest the following:

(1) a free public registry for behaviour names.
    For example, Dublin Core, HTML 4, RDF, XSL, CML all have
    element with specific associated behaviour.

(2) specify the format for the "namespace document".

(3) leave hooks in that document for adding specifications of
    behaviour, should mechanisms emerge.

(4) encourage people to use a client-side URL cache, and include
    long cache expiry times on these documents.

(5) browser vendors could ship a per-generated cache, which is rather
    like a catalog file except that it gets updated automatically as
    entries expire and are fetched again.

(6) the namespace document will contain the names of one or more
    published behaviour sets.

(7) the namespace document will not itself use namespaces, so that there
    is no recursion problem that we can't easily solve.  That way,
    there is no need to wire in the namespace namespace as well
    as the namespace semantics.


  <reference URI="">
  <description>HTML 4.0 Recommendation</description>

Within the namespace document, the URLs must be absolute and exactly
as published by the name registry.

If people argue about who can run a namespace registry, I hereby volunteer
to run one.

We have to solve this problem, not to argue about the simplest way
to avoid solving it.


    [1] ALan Kay, Keynote speech at WWW conference at Darmstadt, 1995

Liam Quin - Barefoot in Toronto - -
Ankh on
Co-author, The XML Specification Guide, Wiley, 1999
Forthcoming: The Open Source XML Database Toolkit

Received on Monday, 22 May 2000 23:11:06 UTC