Re: QNames

[James Clark <jjc@jclark.com>]

Maybe there's a compromise position that everybody can live with.

Element and attribute names appear in documents as QNames; this makes it
natural (to me at least) for patterns to also use QNames for element and
attribute names. If a RELAX NG implementation is going to support the XML
Schema QName datatype, I don't see how it can avoid needing access to the
in-scope namespaces. I therefore don't see any advantage in disallowing use
of QNames for element and attribute names.

However, for datatypes I think the case for using QNames is much weaker.
Although supporting XML Schema makes it natural to identify datatypes by a
URI/NCName pair, but there is no inherent reason why such a pair be
represented by a QName.

Using an inherited attribute to specify the namespace (like with "ns"
currently) works well except when you need to mix lots of different
namespaces.  I suspect it is relatively uncommon to want to mix many
different datatype namespaces.  I think it is much more common to want to
mix multiple element namespaces.

I believe there is a significant user community that isn't very interested
in namespaces at all.  So I think RELAX NG shouldn't force people to deal
with namespaces if they don't want to.  For elements and attributes, RELAX
NG is already satisfactory in this regard: if you don't care about
namespaces, you can just use local names and never specify an "ns"
attribute.  You have to put an "xmlns" attribute on your root element, but
that is not much of a hardship.  However, it is inconvenient to use the
<data> element without exploiting namespaces and QNames: the "ns" attribute
would have to be specified individually on each <data> element.  It can't be
inherited, because that would also affect the namespace of elements and
attributes.

I would therefore suggest not using QNames to identify datatypes. Instead,
add an additional inherited attribute "datatypeNamespace" which can be
specified on any element (similar to the "ns" attribute).  The type
attribute on <data> and <value> would be an NCName. The inherited value of
the datatypeNamespace attribute would determine the URI of the datatype for
<data> and <value>.  (If we do this, we should rename the "ns" attribute,
perhaps to "namespace".)

The datatypeNamespace attribute on the document element would default to
something like

http://relaxng.org/ns/datatype/m.n

which would define the string and token builtin datatypes.

I think this makes things a little bit easier both to use and explain.
Typically users would just put a

  datatypeNamespace="http://www.w3.org/..."

attribute on the document element, and then they would be able to use simply

  <data type="int"/>

James