XML Core WG comments on XQuery/XPath data model

Here are the XML Core WG comments on the XQuery 1.0 and 
XPath 2.0 Data Model Last Call WD at
http://www.w3.org/TR/2003/WD-xpath-datamodel-20030502/

The XML Core WG agreed to submit these as WG comments,
but Richard Tobin (hereon cc-ed) was the primary author
of these.


Expanded name terminology
-------------------------
[2] The draft uses the term "expanded QName" for namespace name /
local name pairs.  This is an unfortunate change given that Namespaces
1.1 has adopted the term "expanded name" from XPath 1.0.

The draft uses the term "namespace URI" in several places.  "Namespace
name" is preferable.


Document order is pre-order
-------------------------
[3.2] Document order is stated to be "in-order", but is in fact "pre-order".


"Inconsistent" data models
-------------------------
[3.3] "Inconsistent" data models are referred to but not defined.
This may not be unreasonable.


Type mapping list incomplete
-------------------------
[3.6] The list defining the type of an element information item is not
complete.  What happens in the case where [member type definition]
or [type definition] is present but hase no name property (because
the type is anonymous)?  Presumably the generated anonymous type
name is used.

The list also applies to attributes, not just elements as stated.


Mapping "no value" and "unknown"
-------------------------
[section 4 as a whole] Presumably in general infoset properties
with no value or which are unknown map to empty values in the data 
model, but this is not explicitly stated.


Document URI example
-------------------------
[4.2.2] "For example, if a collection of documents is returned by the
fn:collection function, the dm:document-uri may serve to distinguish
between them even though each has the same dm:base-uri."  Under what
circumstances can this happen?  Why would documents retrieved from
different URIs have the same base URI?


"Invalid" infosets
-------------------------
[4.2.4] "the resulting Infoset may be invalid": the term "invalid" is
not appropriate here.  For infosets that do not correspond to
well-formed documents it would be better to call the infosets "not
well-formed".

The are more uses of "valid" in this sense elsewhere in the draft.


Zero-length namespace URIs
-------------------------
[4.3.1] (7) "A namespace node whose namespace URI is the zero-length
string": namespace URIs cannot be zero-length strings.  It would be
better to say "whose namespace URI property is the zero-length
string".


Namespace nodes not a superset
-------------------------
"The data model does not enforce a constraint that the namespaces of
an element must be a superset of the namespaces of its parent".  Note
that Namespaces 1.1 will allow undeclaring of prefixes, so this
constraint will no longer apply.  Furthermore, the wording is not
right: even in Namespaces 1.0 a prefix can be rebound, so the
namespace nodes of a child may be quite different from those of the
parent.  The *set of prefixes* of the namespaces is a superset of the
set of prefixes of the parent's namespaces.


Element-declaration vs. node-name
-------------------------
[4.3.2] "The dm:element-declaration accessor returns the xs:QName of
the global element declaration associated with this element."  Surely
this is just the node-name of the element itself?


Namespace nodes and QNames in content
-----------------------------------
[4.3.3] "Some implementations may choose to use only a subset of the
namespaces present in the PSVI".  What are stylesheets supposed to do
to ensure that documents using QNames in content are not broken by
this change?


Errors in element mapping to infoset
-----------------------------------
[4.3.4] In the table, under [children], the value refers to the
[namespace name] property instead of the [children] property.

Under [namespace attributes], the value should be a sequence of
attribute information items, not of namespace information items.


Prefix rebinding forgotten
-------------------------
The last paragraph appears to have forgotten the possibility of
prefix rebinding (cf 4.3.1 above).


Generated attribute prefixes need in-scope namespace
----------------------------------------------------
[4.4.4] The description of [prefix] construction does not explicitly
mention that the owner element's [in scope namespaces] will have to be
modified.


Error in namespace mapping to infoset
----------------------------------
[4.5.4] In the table, under [prefix], the value section has been
cut-and-pasted from elsewhere and is completely wrong.


Pointless constraint on PI target
----------------------------------
[4.6.1] "The string "?>" must not occur within the target or content."
It is pointless to say that it must not occur in the target, since the
target is an NCName and does not allow either of those characters.


Atomic values list incomplete 
----------------------------------
[5] The bulleted list ignores the possibility of lists of unions, etc.


Why are union values sequences?
----------------------------------
And why are values of union type represented by *sequences* of atomic
values?


How do facets affect value construction?
----------------------------------
"In particular the construction takes into consideration the facets of
the type."  Its not clear what this is getting at.  The facets affect
whether the lexical representation is valid, but in most cases don't
affect the value (exceptions are whiteSpace, and the facets of
memberTypes of unions).


Missing infoitem usage
----------------------
[A] The [attribute type] property of attribute information items is
used (when the [validity] property is not present).

The [base URI] property of processing instruction information items
is used. 


Whitespace-only text nodes included?
----------------------------------
[D] "The data model doesn't include whitespace-only text nodes."
Presumably this means that whitespace-only text nodes are not shown,
not that they aren't present in the data model.

Received on Wednesday, 25 June 2003 13:16:33 UTC