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

James Clark <> writes:

> > 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?

I think James is right, and the value has to be determinable for a
QName instance to be type valid, i.e. there must be an appropriate NS
decl in scope.  Yes, this means this type needs to go in the "Only
makes sense for XML documents" section, but I don't see that as a

> 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.

That's just a bug, in my opinion -- Paul?

  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail:

Received on Saturday, 27 January 2001 05:37:18 UTC