No kidding. Actually, the people I talk to worry more about rendering,
or running Java code on, said declared-but-opaque object, but validation
constraints are of equal importance. My usual sound-bite on this is: XML
makes it easy to invent a tag, but what's that buy you? Nothing, unless
you are willing to provide at least one of
(a) a stylesheet for rendering, and/or
(b) some software to *do* something with it.
and if you want to support authoring or update,
(c) validation rules.
I think we can all agree that elements are not interesting without one
or more items from the list above.
Having said that, namespaces all by themselves do have a couple of
useful applications. The most obvious, of course, is for software that
understands and knows how to deal with some particular element (e.g.
MathML <Integral> or HTML <FORM>), and simply wants to run through
an otherwise-opaque document, find the elements he knows how to deal
with, and do his stuff. Namespaces provide a reliable and robust way
to enable this.
I don't really agree with Paul Prescod's argument that the current
namespace draft invades schema turf. It does state that presumably
namespaces will in general have associated schemas (surely no-one here
disagrees?), but it bends over backward to avoid relying on the existence,
availability, or format of these schemas. At the moment, based on some
off-line experimentation, I do think that the namespace facility will
lend itself quite elegantly to the construction of partial composable
schemas, the need for which is not in doubt. -Tim