- From: Biron,Paul V <Paul.V.Biron@kp.org>
- Date: Mon, 29 Jan 2001 14:43:29 -0800
- To: "'James Clark'" <jjc@jclark.com>, www-xml-schema-comments@w3.org
> -----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