Re: QNames

[James Clark <jjc@jclark.com>]

> I am not sure if RELAX NG will always support QName.  If I make a subset
of
> XML Schema Part 2, I will definitely get rid of QName as well as datatypes
for
> date and time.  Also, different libraries (e.g.,  datatype libraries by
> David RR Webber) will be in use.

Even if there are datatype libraries that don't support QName, still the
spec needs to support XML Schema Part 2, which means that the spec has to
deal with in-scope namespaces.  Also I expect/hope that implementations of
RELAX NG will allow different datatyping implementations to be plugged in,
rather than being tied to any single datatyping implementation.  I would be
surprised if any RELAX NG implementation did not provide interfaces
sufficient to allow an implementation of XML Schema Part 2 to be plugged in.
The net result is that I believe in practice RELAX NG implementations will
have to support in-scope namespaces. Also in general programs manipulating
RELAX NG schemas will need to deal with in-scope namespaces.  If a RELAX NG
schema restricts itself to a datatyping library that doesn't support QNames,
then admittedly it can be manipulated without regard to in-scope namespaces.
But allowing QNames for element and attribute names in a RELAX NG schema
doesn't make things any worse: if a user wishes for some reason that their
schemas be capable of being manipulated without worrying about in-scope
namespaces, then it is already possible for them to avoid QNames and instead
use explicit namespace attributes, just as they can, if they so choose,
avoid using the QName datatype.

The reality of the XML world today is that XML tools have to deal with
in-scope namespaces.  There are too many important languages that use them,
notably XSLT and XML Schema.  Admittedly, in-scope namespaces complicate
processing.  But other tools and standards already have to deal with this;
for example, XML canonicalization already deals with in-scope namespaces.
And the standard XML tools do deal with in-scope namespaces: SAX and DOM
both fully support them.

Thus, even if you think using in-scope namespaces is a terrible idea, there
is no practical advantage, with the XML world as it is today, in eschewing
reliance on in-scope namespaces. RELAX NG users would still have to pay the
cost of in-scope namespaces in terms of increased tool complexity, because
they are so widely used elsewhere, yet they would not get the benefit of
increased convenience and ease-of-use to compensate for that cost.

> 1.  Always spell out the URI or use inheritanace of the ns attribute
>
> Yes, this is verbose and error-prone.   But this works in some cases:
>
> Case 1: we use namespaces rarely
> Case 2: inheritance of the ns attribute is good enough
> Case 3: we will later introduce a mechanism like RELAX Namespace,

That's certainly simple and coherent.  On the other hand, it will make RELAX
NG very cumbersome for declaring patterns that mix namespaces.  Instead of

<attribute name="xml:space">
  <choice>
    <value>default</value>
    <value>ignore</value>
  </choice>
</attribute>

users would be forced to write

<attribute name="space" namespace="http://www.w3.org/XML/1998/namespace">
  <choice>
    <value>default</value>
    <value>ignore</value>
  </choice>
</attribute>

I cannot see that this is an improvement.

> 3.  The proxy attribute
>
> 1) Namespace declarations
>
> A grammar element begins with namespace delclarations (for the lack of a
better name).
> A namespace declaration declares a namespace URI and attaches a proxy to
it.
>
> E.g.,
>
> <grammar>
> <namespace name="http://www.example.com" nsproxy="e"/>

Then the order of the children of a <grammar> element becomes significant.
And how do I declare namespaces if I am not using a <grammar>?

And what about <value>s of type QName?  With this proposal, there would seem
to be two choices, both unattractive:

(1) the prefix is expanded using the namespaces declared by namespace
declarations; this means the user has to deal with two different ways of
declaring bindings between NCNames and namespace URIs

(2) the prefix is expanded using the bindings declared by <namespace>
elements; this means that <value>s of type QName are confusingly differently
in the schema and in the instance

The proxy attribute seems to me even worse than the option of spelling
namespace URIs out explicitly.

James