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

> -----Original Message-----
> From:	James Clark [SMTP:jjc@jclark.com]
> Sent:	Friday, January 26, 2001 9:57 PM
> To:	www-xml-schema-comments@w3.org
> Subject:	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.
> 
I should have just kept my mouth shut, since the point I was trying to make
was very minor and seems to have been missed anyway.

True, at instance document validation time, there must be a NS decl in scope
(as James points out, so that the lexical space to value space mapping is
possible).  True, in order to serialize a type-valid instance in an XML
document the serialization must also serialize a NS decl (so that upon
re-validation the serialized instance will be type-valid).

However, there is no requirement that a type-valid value from a given
datatype EVER be serialized in an XML document.  One is perfectly free to
manipulate schema components in memory, using only internal representations
of values from the value space (i.e., there is no requirement that a literal
every be constructed).  Since the value space is the set of {namespace name,
local part} pairs, prefixes and namespace declarations are NOT a requirement
for this datatype.  That was my only point.

> 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.
> 
I'll have to confir with my co-editor before answering this one.

> 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.
> 
Sorry, my fault.  Originally, the order relation for QName was inherited
from string (since QName was a distance descendant of string).  Two things
have subsequently happened: QName became a primitive and string became
unordered.  At the time QName became primitive, I asked the WG if they
wanted QName to remain ordered: the answer was yes.  We apparatently forgot
to explicitly state the order relation for QName.

The order relation should be stated as a 2 level lexicographic sort, first
by namespace name, then by local part.

pvb

Received on Monday, 29 January 2001 17:58:00 UTC