- From: XML Query <xmlquery@us.ibm.com>
- Date: Mon, 2 Feb 2004 11:07:54 -0800
- To: public-qt-comments@w3.org
- Message-ID: <OF3E9BDB8E.A5795AFF-ON88256E2E.0066C6F0-88256E2E.00691B7A@us.ibm.com>
Data Model Section 6.2.2 (Element Nodes--Accessors): The dm:string-value accessor does not seem to be defined in terms of the properties of an element node. This problem has many manifestations. For example, (a) "If the element type is xs:string, or a type derived from xs:string, returns that string." Eh? Returns what string? Does it mean that the value returned is the content property of the child text node? (b) "If the element type is xs:anyURI, returns the characters of the URI." What URI? Again, are we talking about the content of the child text node? (c) "If the element type is xs:QName": this bullet has many problems. It discusses a "value" but does not specify where the value is found. It discusses the case when "in-scope namespaces map the default namespace to any namespace URI". Does this mean that the default namespace is a specific (rather than "any") URI? It refers to an error, "default namespace is defined". But this error needs a better description--certainly it is not an error simply to define a default namespace. Also, the list of subcases seems to be incomplete. The first bullet deals with the case when the "value" has no namespace URI and the default namespace satisfies some (poorly specified) condition; but what about the case when the the "value" has no namespace URI and the default namespace does not satisfy this condition? (d) "If the element type is xs:dateTime, . . .": This paragraph requires the "original lexical representation" to be returned by the string-value accessor. But I believe there is no such requirement--isn't it possible that the original lexical representation might have been normalized into some different but equivalent representation? In general we do not attempt to preserve "original" lexical representations. Also, presumably this section applies to subtypes of the date/time types as well as the date/time types themselves. Also, this section describes how to compute a string-value from a "normalized value" and an "explicit timezone", but these things are not among the listed properties of an element node. (e) "In all other cases, returns the concatenation of the string-values of all its text node descendants in document order." Finally, something that is actually found in the data model! Unfortunately, this sub-bullet is under the higher-level bullet where the "element has a simple type or a complex type with simple content." But in these cases, the element node has only a single text-node child, so why are we talking about "descendants"? (f) If the element has a simple type or a complex type with simple content, why doesn't the string-value accessor simply return exactly the content of the child text node? If the child text node doesn't contain the string-value in these cases, then what does it contain?
Received on Monday, 2 February 2004 14:46:36 UTC