XML Core WG comments on the XQuery/XPath Data Model [3rd send]

Here are the XML Core WG comments on the XQuery 1.0 and XPath 2.0 
Data Model draft. 

The draft is at

  http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/


Section 1 para 5:

It would aid readability if the introduction stated explicitly that
items were either nodes or atomic values, rather than just having a link.

Section 2.3:

No mention is made of identity for atomic values.  This may be
deliberate.

Section 3 para 6:

Typo - "sequences of documents nodes" should presumably be "sequences
of document nodes".

Section 3.3 para 1:

Typo - "any combination assessment modes" should be "any combination
of assessment modes".

Section 3.3.1:

The list of cases for determining the type is still not quite right:
it does not cover the case where [type definition] or [member type
definition] is present but does not have a {name} property.  It should
be something like:

  If [member type definition] exists:

     If its {name} property is present: the {target namespace}
     and {name} properties of the [member type definition].

     Otherwise, the namespace and local name of the appropriate
     anonymous type name.

and likewise for [type definition].

Section 3.3.4:

Typo - "Retreiving" should be "Retrieving".

Section 5.3:

The list of mode kinds names omits "namespace".

Section 6.1.3 (and elsewhere):

The capitalization of node kinds is inconsistent.  For example, here
you have "Document Node" but earlier you had "document node".

Section 6.1.3 under "children":

When constructing a document node from an infoset, there cannot be any
character information items among the [children].

Sections 6.2.1, 6.2.2 and 6.3.2:

There is a strange asymmetry between elements and attributes:
attributes have a string-value property, and elements don't, though
they both have dm:string-value accessors.  Furthermore, instead of the
definition of the dm:string-value accessor for attributes saying that
it returns the string-value property, it has a long description of the
construction of the value.

If the dm:string-value accessor returns the string-value property, it
should say so, and the description of the value's construction should
be in the natural places (6.3.3 and 6.3.4).  If it does *not* return
the string-value property, this needs to be explained and justified.
And what is the use of the string-value property if no accessor
returns it?

The descriptions of the dm:string-value accessors are also
unsatisfactory in themselves.  They take the form "if the type is
<type>, then <something about that value>".  What value?  No value has
been mentioned, only a type.  It must be the value whose type is
<type> - but is that the same as what dm:typed-value returns?

Section 6.2.2 and elsewhere:

The types xs:anyURI, xs:QName, xs:dateTime, xs:date and xs:time are
described specially.  Presumably these descriptions also apply to types
derived from these types.

Section 6.2.4:

In the first sentence, "effected" should be "affected".

Under [children], the creation of a text child for the [schema
normalized value] and the removal of the original text nodes seems
unnecessarily complicated.  It would be simpler and clearer to leave
the children alone, and say that the element has a string-value
property whose value is the [schema normalized value].

Section 6.3.2 under "dm:string-value":

Types other than xdt:untypedAtomic, xs:anyURI, xs:QName, the time/date
types, and types derived from xs:string, are not mentioned.  Numbers
for example.

Section 6.3.4 under "type":

"no part of the subtree that contains the node" is wrong.  There are
many subtrees containing the node, including the entire document!  It
should be "neither the node nor any of its ancestors".

Section 6.4.3 under "parent":

Be more explicit: instead of "The element to which the Namespace Node
applies", say "The element in whose [in-scope namespaces] property
the namespace node appears".

Section 6.7.1:

"A text node must not contain the empty string as its content".  But
according to 6.2.4, text nodes may arise from the [schema normalized
value] property of an element, in which case they may be empty strings
(because the [schema normalized value] may be an empty string).  The
natural solution would be to say that no text node is added in 6.2.4
if it would be empty, but see also our comments on that section above.

Section 6.7.4:

This does not discuss text nodes constructed from [schema normalized
value] property of an element as described in 6.2.4.

Paul Grosso acting as chair of the XML Core WG, so any responses
should be sent to w3c-xml-core-wg@w3.org rather than me personally.

Received on Friday, 13 February 2004 11:00:19 UTC