RE: what should I expect for validation of attributes of type QName?

> One slight correction. The QName datatype does NOT require there to be a NS
> declaration in scope.  To quote from the spec:
> 
>         QName represents XML qualified names. The value space
>         of QName is the set of tuples {namespace name, local part},
>         where namespace name is a uriReference and local part is
>         an NCName. The lexical space of QName is the set of strings
>         that match the QName production of [Namespaces in XML].
> 
> There is no requirement, per se, that there be a namespace decl in scope.

This doesn't make any sense to me at all.

> Practically speaking, however (which is probably where henry is coming
> from), the only way the processor can now how to map literals from the
> lexical space (which contain prefix:localPart) to values in the value space
> (which contain {_namespace URI_, local part} pairs is for there to be a
> namespace decl for _namepace URI_ that binds prefix to it.

Right.  So how does it make sense to allow a QName with an undeclared
prefix?  It doesn't correspond to any value in the value space. Surely
it's fundamental that every value in the lexical space represents some
value in the value space.  If it's not, I can't make any sense of the
whole conceptual apparatus described in Section 2.

For example, what happens if QName has an enumeration facet? Do I
compare the QNames or the namespace URIs/local names? If the latter, how
do I deal with an undeclared prefix?

Also I see the length facet applies to QNames.  Facets constrain the
*value* space, but it's not obvious what the length of a namespace
URI/local part pair is.

Also C.1 says QName is ordered, and it has the
max/minInclusive/Exclusive facets.  But the spec seems to be silent on
what the ordering relation is.

James

Received on Saturday, 27 January 2001 01:00:04 UTC