Re: [xml-dev] RE: Namespace use cases

[rjelliffe@allette.com.au]

I think there are three distinct cases.

The first is the declarations used for namespaces on elements and
attribute names: the subject of the Namespaces in XML spec. This took
multiple thousands of emails last time, so good luck on it this time.

The second is the namespaces used for Qnames in element and attribute
values. XSLT went one way, but I think it is the wrong way because it
fudges the difference between data and markup. Schematron has explicit
elements and this has been very smooth: developers don't worry about
default namespaces, they only need to look in a single place.

The third is that the role of namespace is challenged by emerging
maintenance requirements. The generation of schemas developed without
version attributes now face the challenge of how to cope when they need a
major version upgrade, and namespaces are the obvious and (I think)
correct thing to use as a slicker kind of major version number. (It is not
that I am trying to say that namespace = schema, however namespace = major
version = schema family or base schema is OK.)

The rub is that XML now is used for software that is very far from the
SGML legal-military-industrial publishing case, where the correct response
to invalidity was rejection of the document. A hallmark of small-o office
document systems is the need for graceful degradation: you want as much as
can be retrieved.

Our current namespace infrastructure, such as XSLT, has no story about how
to cope with this kind of thing. It is a real challenge for standards
developers in the office area at the moment.  I worry that our schema
languages and normal XML technology do not provide an adequate foundation
for this kind of thing, dramatically decreasing the value of using XML at
all.

Of course, there are bits and pieces: XSD has its type derivation
mechanism and the new alternative mechanism, but it is at the node level
not the namespace or schema or document level; Schematron has phases and
parameters; ISO DSRL allows renaming; RELAX NG allows notAllowed which can
switch in and out;  OOXML MCE allows alternative sections in the same
document where the system chooses the optimal version.

But these all fall over in the most common problem cases: I have last
year's software and I get sent a document with this year's
namespace/version, or I get sent a document with 10 years-ago's
namespace/version. The document itself needs to carry around some metadata
to say which what the relationship between its namespaces and previous
ones are (e.g. namespace X is a subset/superset/dialect of namespace Y) in
a way that allows an application to make a good stab at figuring out what
to do, if that is what the user does. OOXML has this problem right now;
ODF has it also in proposals to consolidate attribute names; HTML has had
it for a long time, with all the different dialects.

May I be cynical? I expect that discussions on namespaces will focus on
the first, since they are all different W3C WGs.  And consequently the
needs in the third area, which is surely just as important as HTML since
it involves spreadsheets as well as literature, will be pushed aside and
ignored. The SML discussions here a decade ago were a call for more
simplicity which, by focussing XML-DEV kind of people's attention away
from the actual standards agenda, actually promoted the greatest increase
in complexity in SGML/XML's history: XSD.  Please lets not make the same
mistake again, even though syntax is so amusing. The big items on the
standards agenda at the moment are HTML5 and ODF/OOXML (both what they are
and what they need in the way of enabling standards.) Why not hop out of
the armchair and get involved in those?

Cheers
Rick Jelliffe