Data Model Last Call 1 Comments

I am trying to put a few statements together and, at the moment at least, 
they don't quite add up for me.

In XPath Chapter 2 it is stated, "Each node has a unique node identity."

In Data Model Chapter 6 it is stated, "A sequence has no identity".

In XPath Chapter 2 it is stated, "An item is identical to a singleton 
sequence containing that item."

However, if the item in a singleton sequence is a node then it seems that the 
sequence with a single node has no identity. However if the node exists "on 
its own", as it were, it does have identity. ... If you see what I mean. :)

Is there an inconsistency? Or have I missed a caveat somewhere?

Perhaps the seeming problem can be solved by adding some judicious qualifying 
phrase in an appropriate place?

There may be an editorial typo in the specification
of the one-argument base-uri.  The result is that it
is unclear where the base-uri of a text node
be non-empty.  I think the intent is "yes",
in which case I think this one-word fix will help.  Change
"The base-uri of all other node types is the empty sequence."
to
"The base-uri property of all other node types is the empty sequence."
 From the context, that appears to have been the intent.

Both the Functions and Operators and the Data Model documents have
the same problem.

In looking at 3.2 in Data Model there is a description of document order in 
*documents* and mention of free-standing nodes. But there appears to be no 
mention of document order in fragments.

It seems to me that fragments may have document order. 

Was it a conscious choice not to discuss this in the Data Model 
specification? Or is it intended that the document order which is specified 
for *documents* is also intended to apply to fragments?

I have a supplementary question on fragments which I will send in a few 
minutes. It may impact on this question.

On reading the Data Model document it seems to me that the term "fragment" is 
used in a way which is ambiguous and potentially confusing.

In 4 it is stated that "A tree whose root node [is not a document node] is a 
fragment.".

However in 4.2.3 it is stated, "When a data model fragment is created from 
the PSVI, a document information item is mapped to a document node.". I take 
that to indicate that a "fragment" acquires a document node. But, if I 
understand 4 correctly, it is then by definition not a fragment.

I am not sure if the intention is that "fragment" and "data model fragment" 
are intended to have different meanings (if so that should be clarified) or 
if they have the same meaning and the descriptions in 4 and 4.2.3 are 
inconsistent.

In 3.3 of Data model mention is made of "sequences of fragments and sequences 
of documents". I assume that the intention is to refer to sequences of "root 
nodes" and sequences of "document nodes"?

I think I know what is intended but the way it is phrased opens the 
possibility of sequences of things other than atomic values and nodes. Some 
rephrasing seems desirable.

In the penultimate sentence of 3.3 of Data Model mention is made of 
serialization via the infoset.

However, the infoset is not mentioned anywhere in the new Serialization WD, 
as far as I can see.

Two suggestions:
1. There should, perhaps, be a cross reference from Data Model to 
Serialization
2. The descriptions of serialization might better be more clearly aligned 
between the documents.

In 4 of Data Model mention is made of fragments which, it is stated, don't 
have a document node as "root node".

Which other node types can be a "root node"? It isn't stated. Can all 6 other 
node kinds be a "root node"? If so it should be stated, if not then that too 
should be made clear.

Can, as an edge case, a "tree" have a "root item" i.e. an atomic value? Not 
much of a tree, I admit. :)

In a Note in 4.2.1 it is stated that document nodes and XPath 1.0 root nodes 
are essentially identical. It seems a little perverse, to me at least, to use 
the term "root node" in XPath 2.0 to contrast with "document node" (as in 4) 
while recognising that a document node and an XPath 1.0 root node are very 
similar.

As a final point re 4, the term "root" (unqualified) and the term "root node" 
are both used in the same section. Are they synonymous? Or is some 
distinction intended?

In 4.1.1 of Data Model, in line 1, reference is made to a "uri reference". 
Should that be "URI reference"?

In 4.1.3 of Data Model, in the first bullet point, the term "qualified name" 
is used. I think you may have intended to use "expanded-QName" which would 
seem to correspond better to the returned xsd:QName type.

Can a root node which is not a document node be a parent node?

The last sentence in 4 implies that a fragment has a "root node" which is not 
a document node. Can such a "root node" have child nodes or, more precisely, 
be a parent node?

In numbered points 5 and 6 I suggest that "document D" be replaced by 
"document node D" and, in 7, "a document" be replaced by "a document node".

"emtpy" should be "empty"

In the second line of paragraph 2 of 4.2.3 reference is made to "Element, 
Processing Instruction, Comment and Text nodes". Since dm:node-kind() returns 
node kinds with lower case initial letters should that not be reflected here?

Section 4.3.3. of the Data Model draft states:

     If the [validity] property exists and is "valid" and the 
[attributes] property contains an attribute with the local-name "nil" 
and the namespace URI "http://www.w3.org/2001/XMLSchema-instance", 
then "true", otherwise "false".

I do not see why validity should be required for an element to be 
nil. The mere presence of the xsi:nil="true" attribute should be 
sufficient. Or just maybe it should also be required that the element 
be empty. However, there's no reason it needs to be valid. I have 
profitably used xsi:nil in documents without any schema or DTD.

I suggest deleting the phrase "the [validity] property exists and is 
"valid" and "

> From section 5.
> quote.
> The value space of the atomic values is the union of the 
> value spaces of the nineteen primitive XML Schema types. unquote.
> 
> Does this imply that no types (or at least atomic types) from 
> any other source are valid within this data model? 
> 
> Is this lockout for anything other than XML schema types or 
> some direct derivation?
> 
> Or more specifically, lockin to XML schema types?
> 

We have added statements in the XPath and XSLT specifications saying that
the set of types may be extended by implementors, I think the Data Model
document probably needs to say something to reflect this.

From section 5.
quote.
The value space of the atomic values is the union of the value spaces of the
nineteen primitive XML Schema types.
unquote.

Does this imply that no types (or at least atomic types) from
any other source are valid within this data model? 

Is this lockout for anything other than XML schema types or
some direct derivation?

Or more specifically, lockin to XML schema types?

I am concerned at the use of the word "document" in the Data Model document.

The term "document" seems to be used for at least three purposes, as far as I 
can see.

In 4.1.4 we read, "A tree whose root node is a document node is a document". 
Well, no it isn't, not really.

It seems to me that some distinct term ... "document tree"? ... should be 
used where the sense of 4.1.4 is intended,  to avoid confusion with XML 
documents and with document nodes.

In 4.2 we find a heading "Documents" which I think is an informal shorthand 
for document nodes. Or is the 4.1.4 "document tree" sense intended in parts?

In 4.2, we have ".... XML documents. Documents have the following properties 
....". I assume that by "Documents" it is intended to refer to "document 
nodes"? XML documents qua XML documents certainly don't have the stated 
properties.

It is disappointing to see these ambiguities persisting in the Data Model 
document. I seem to recall raising this issue some time ago. In a formal 
specification document I think it ought to be tidier and that a greater level 
of precision and consistency should be aimed for and achieved. Not least when 
the specification is deemed to be in Last Call.

There are similar ambiguities/inconsistencies in the use of the term 
"element" to those which I pointed out re the use of "document".

For example, in 4.3 the heading is "Elements", I assume that what is intended 
is "Element Nodes".

In 4.3.1 we read "... XML elements. Elements have the following properties 
..."

But elements simply don't have the properties stated. Element nodes may. If 
that is the term which was intended it should be used.

In each of the headings of 4.2 to 4.8 inclusive the word "Nodes" is omitted 
and should, for clarity, be present.

In 3.3 it is claimed that the data model supports "sequences of documents". 
As far as I am aware it doesn't.

I assume that what was intended was "sequences of document nodes".

If, however, the above was intended to convey the notion that a sequence may 
consists of nodes, atomic values and documents then other parts of the DM 
document need to be brought into line. I assume that simply adding "nodes" 
solves the seeming inconsistency.

In 3.3 of DM how is an "inconsistent data model" defined? If they are 
forbidden it seems sensible to have a clear definition what is being referred 
to.

In 3.4 it is stated that dm:type, in the absence of type information, returns 
xs:anyType or xs:anySimpleType. However in 4.1.7 it states that the type 
returned in such a circumstance will be unique and implementation-defined.

On the face of it the statements are inconsistent.

I am having problems deciphering the following sentence in 3.6:

"If a PSVI is not available, then the data model is constructed from the 
Infoset in a manner that is compatible with the expectations of well-formed 
or DTD-validated parsing of an XML document."

Whose expectations are being referred to?

What are the expectations?

The sentence seems to be saying something like, "The data model will be 
constructed the way you expect for well-formed or DTD-validated XML 
documents.". But that seems to second guess what I expect which may not be 
what you assume I expect.

Something more precise in terms of wording would aid comprehension, I think.

In the first bullet point in 4.1.3 it is stated that a "qualified name" is 
returned. As the term is used in Namespaces in XML, I don't think that is 
correct.

I think you may have intended to say "expanded-QName".

In the second bullet point of 4.1.3 it is stated that a processing 
instruction returns an xs:QName but it has no namespace URI.

It seems to me that something that has no namespace URI may not be consistent 
with the definition of xsd:QName in W3C XML Schema. What is described in 
4.1.3 is half a tuple.

In the Returns column for dm:string-value I suggest you replace "document in" 
with "document node in".

DM 4.5.2 and G.4 say that dm:parent of a namespace node
is "the parent element node".  It does not define
what this means.

However, none of the namespace nodes in D Example
show a value for dm:parent, though dm:parent is
shown for other nodes.

Should there be a constraint in 4.3.1 and/or 4.5.1 that
is a namespace node has a parent, then it should be among
the namespace of its parent?  The converse constraint would
prohibit sharing of namespace nodes, as in D example.
The issue should at least be mentioned.

One solution is to just define dm:parent of a namespace as ().

appropriate namespace prefix, as described below"
 
I can't seem to find that description.

<http://www.w3.org/TR/xpath-datamodel/> , section 4.3.3 PSVI to Data Model
Mapping, contains
parent 
The value of the [parent] property.
I wonder whether this is correct, as I assume the [parent] property is an
infoset item.

Jonathan Robie scripsit:

> The Data Model, which is in Last Call, is particularly important right 
> now - we have tried to design it so that we support XML Schema, but also 
> merely-well-formed XML and XML governed by DTDs. We have also tried to 
> keep it relatively simple. If people have time to review only one 
> document, this is the one.

I have reviewed it, and I'm copying this to the public comments list.

I would like to see the Infoset-only model nevertheless process xsi:type
attributes as a special case.  This would make it possible for a process
to serialize information about element types, at least, directly into
an XML document.

In addition, an xdt:attributeTypes attribute would be a Good Thing:
this would have list-of-QName type, and would alternate an attribute name
with its type.

Adopting these very slight modifications of Infoset-only rules would
allow upstream processes to specify type information (which is AFAICT
the main contribution of the PSVI to the data model) without the overhead
of a full PSVI.

In section 4.6.1, Overview (of Processing Instructions), the sentence
"Namespace nodes must satisfy the following constraints."
should be 
"Processing instruction nodes must satisfy the following constraints."

Untyped data will map to untypedAtomic and untypedAny (which may get
renamed) not anySimpleType and anyType.

Introducing a new structure, datetime tuples, to capture the info you 
want for datetime types is a good idea, but why not use a real, named 
XML Schema type, as is done for duration?  Of course, it's not 
completely analogous because the value space is expanded by the tuple 
rather than restricted as is the case for the new duration types. The 
tuple seems too magical when there are more transparent options 
available.

Here is a simpleType that captures (a superset of) the value space for 
the tuple.

   <xs:simpleType name="datetimeTZ">
     <xs:annotation>
       <xs:documentation>
         A "list" of a datetime/duration union with the convention
         that list always has two items: the first item is a datetime
         and the second item is a duration.
       </xs:documentation>
     </xs:annotation>
     <xs:list itemType="datetimeORduration"/>
   </xs:simpleType>

   <xs:simpleType name="datetimeORduration">
     <xs:union memberTypes="xs:datetime xs:duration"/>
   </xs:simpleType>

Most datetime F&O functions would operate on xdt:datetimeTZ instead of 
xs:datetime, just as functions operate on xdt:*Duration instead of 
xs:duration.

While there is a lexial representation for datetimeTZ (as a two-value 
list), F&O or FS would define functions/casts to convert datetimeTZ to 
the timezoned datetime lexical representation and back.

I'm sure the WG has been round and round on this issue, but in case you 
have considered the above option, please do.

There appears to be an inconsistancy between 
the use of implementation-defined and same, without the hyphenation.
I think the functions document uses it without hyphenation, others
are more consistant.

Prodded by someone in my company, I finally took the time to read the 
data model spec (http://www.w3.org/TR/xpath-datamodel/).  I had a few 
thoughts, which I hope will be helpful.  I apologize in advance that 
I've not been following the mailing list until now, so some of my issues 
may be redundant with what others have already said.

xdt:untypedAtomic is only defined by inference, as near as I can tell. 
Shouldn't it be defined somewhere?  Is it, and I just missed it?

Notation – in the paragraph immediately after the example, the term 
"Item" is used, but doesn't correspond to anything in the example. 
Actually, I found the example confusing, employing the word "Node" to 
refer to both the concept of a node, and the category of a node, so far 
as I could tell.

Spec uses the xdt prefix without defining it anywhere that I could find. 
It first shows up in the example here.

anonymous type names - "globally unique" - this sounds suspiciously like 
a GUID or UUID. Does this need to be unique for all time, or merely the 
duration of the processing? In other words, how "global" is global meant 
in this context? Must an anonymous type name conform to a valid NCName? 
Or alternatively, must it explicitly NOT be a valid NCName?  Should 
these be stuck in a standard namespace, so as to guarantee they won't 
conflict?  Or alternately, should the requirement be that the namespace 
of the anonymous type be in the same namespace as its first 
non-anonymous ancestor?  I understand the desire to name the otherwise 
anonymous types, but tightening up the definition here could be 
extraordinarily useful downstream, or at least help clarify intent.

Section 3.6.1 – I found that the use of "tuple" here confuses matters 
for me greatly, in that sequences cannot hold tuples, only atomic values 
or nodes. Perhaps what is really being done here is the definition of an 
alternative simple type that represents date time values? If introducing 
an xdt:untypedAtomic, why not just introduce a new pair of types for 
dateTimes with/without timezones to work around the issue?

Section 4.1.1 – dm:base-uri

The three paragraphs confused me with the first few readings, especially 
with regard to empty versus non-empty behavior. I get the idea, but it 
seems contradictory to first say that something is empty, and then to 
say if it is empty, it takes the value of its parent, of course, that is 
not what it is saying, but that is how I read it first.  Additional 
insertions of the appropriate "accessor" or "property" term in relation 
to "base-uri" would help here.

Section 4.3.2 - the definition of the dm:element-declaration() accessor 
is confusing. Some context as to what point this serves, as well as an 
example would have helped me.  I've read this several times, and I still 
don't get it.  Is there any way to define this without referencing yet 
another external specification?  Also, the sentence before the 
definition reads "One additional accessors is defined on element 
nodes:", but "accessors" should not be plural.

4.5 - Namespaces - does the reserved "xml" prefix need mentioning here, 
or is that understood?

4.6, 4.7 - does it make sense to have accessor functions for the 
specific characteristics of comments and PIs?

Section 6: Says "Sequences are 'flat', they may not contain other 
sequences," and immediately thereafter, "An important characteristic of 
the data model is that there is no distinction between an item (a node 
or an atomic value) and a singleton sequence containing that item. An 
item is equivalent to a singleton sequence containing that item and vice 
versa." These two statements are somewhat contradictory, in that if a 
single item can be considered a sequence of one item, then a sequence 
can implicitly contain a sequence of sequences with only one item. I 
understand what is meant, but think the wording could be more precise.

Section 4.3.2 of the data model document does not appear to reflect the
decisions of the working group in relation to mixed content: specifically,
that the type of an element declared as having mixed content should be the
string value, as an instance of xdt:untypedAtomic.

The correct rules are stated in section 4.1.6. It is not clear why 4.3.2
attempts to restate the same rules in a different way. In fact, the overall
structure of section 4, which presents the same accessor functions organized
first by function and then by the kind of node that they apply to, seems
designed to lead to inconsistencies of this kind.

The correct place for a diagrammatic representation of the type hierarchy
used in the data model would appear to be in the data model book; other
specifications such as F&O should refer to it rather than repeating it.

There is no good overview of the type hierarchy anywhere, the information is
completely scattered. In particular, there is no explanation of the fact
that there are actually two independent but related type hierarchies, one
for "values" (of expressions) and one for "content" (of nodes). The fact
that we refer to both these overlapping spaces as having types means we need
to make it much clearer that there are two different spaces, and to show how
they are related to each other.

In most database systems, documents are likely to have properties extraneous
to the actual XML content of the document, and these properties are often
useful for retrieval. Examples of such properties include document names,
URIs, dates of creation and modification, ownership, security levels,
document size, associated schema, document version, and so on. They may also
include user-allocated properties, for example the approval status of the
document in some publication workflow.

Many XML database systems are likely to want to offer other interfaces in
addition to XQuery. A popular interface for content management systems is
the WebDAV interface. WebDAV allows a document to have an arbitrary set of
properties, including properties under the control of the system and
properties under the control of the user.

Document nodes constructed by a query may also have properties, for example
the MIME media type, the serialization parameters, and the intended
destination of the document when serialized.

We think it would be useful to extend the data model to allow a document
node to have such a set of properties. It should be possible to query these
properties, and to set them when constructing a document node. It should be
understood that the properties are accessible to applications but that they
are not serialized as part of the document content.

A possible (though controversial) design that would meet this requirement is
to allow a document node to have attributes.

section 3.2 Document Order of the XQuery 1.0 and XPath 2.0 Data Model
uses the term "stable" to characterize orders.
I do not find any definition in this document what a stable order is.

Do you mean, if two nodes A and B whose order is implementation-dependent
are in some concrete order then this order doesn't change within this
model (for the lifetime of this instance; never)?
Does it have to be the same order between two invocations of an implementation?

Moreover, regarding distinct documents, the specification says

   "The relative order of nodes in distinct documents is 
   implementation-dependent but stable. In other words, given two 
   distinct documents A and B, if a node in document A is before a 
   node in document B, then every node in document A is before every 
   node in document B."

That sounds as if the second sentence ("In other words, ...") is a
conclusion or an explanation of the term "stable order", but I can't 
apply this meaning to attribute or namespace nodes.

I believe this section needs a clarification.

I would appreciate if the XQuery 1.0 and XPath 2.0 Data Model defines
whether a default null namespace is represented by a namespace node
or not.

Section 4.5 Namespaces says in 4.5.1

   2 The namespace prefix may be the empty sequence. If the URI is the 
     zero-length string, the prefix must be the empty sequence.
     
Hmm, there might exist namespace nodes without prefix and without URI.
Such a node would be created by an xmlns="".
OTOH, I would interpret this as an undeclaration of the default namespace, 
thus it removes an existing namespace node (that would be present otherwise).

The specification should unambiguously state, under which circumstances
such namespace nodes come into live.

I prefer not to introduce such "null" namespace nodes. There shouldn't be a 
difference between <foo /> and <foo xmlns="" />

One more question:
Are situations imaginable that a namespace node doesn't have a parent?
Since the specification thinks so I would like to see a comment just
as for attribute nodes.

---

In http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0225.html,
Michael Kay replies:

I agree with you, I think the text is wrong. There should never be a
namespace node whose string value (namespace URI) is zero-length, as
namespace nodes always represent the declaration of a namespace and not the
undeclaration.

I think that it is now possible in XSLT to create a parentless namespace
node: viz

<xsl:variable name="ns" as="node()">
  <xsl:namespace name="my">namespace.uri</xsl:namespace>
</xsl:variable>

Though this probably isn't what was envisaged when the DM spec was written -
at one time there was an idea that namespace nodes would be "shared" between
elements in some way.

Consistency of style, within a document and between documents, is 
important.

For example, in the Data Model document there are two different styles 
of definition. One style is [Definition: here is the definition.] The 
other style is to italicize the defined word - for example, the 
definitions of "document" and "fragment" in section 4 "Nodes" second 
paragraph. Note that elsewhere in the same document, for the most part, 
italics serves other purposes than definition: to indicate distinguished 
values ("valid" "invalid" and "notKnown" in 3.6 "Mapping PSV Infoset 
additions to Types" second paragraph) or emphasis ("If the validity 
property *does not exist*..." later in the same section).

If there is a semantic difference behind the two styles, there should be 
a clear reason why some definitions use the more formal "[Definition: 
here is the definition.]" style, while others just use italics. And the 
document should explain the two conventions and the reasons for having 
both of them.

*Data Model, **Section 1, Introduction. *The distinction between data 
model and value in the second paragraph is good, but I think a third 
concept should also be introduced and given a name. This third concept 
is the set of all values currently under consideration during the 
execution of some processor (XSLT, XQuery, etc.) using the data model. A 
possible name for this concept is "data set". Thus the three concepts are:

"data model" - the abstract framework specified by this specification
"data set" - a concrete realization of the data model at a particular 
point in the execution of a processor
"value" - a value in a data set.

*Data Model, Section 4. Nodes. *It seems that a node is similar to, but 
not exactly the same as, an information item, as found in the Infoset 
recommendation and enhanced with the PSV contributions in the XML Schema 
Part 1 recommendation. It would be helpful to say this explicitly, 
especially since you share the term "property" with the Infoset, so it 
is easy to form the impression that a node is simply an information 
item. The reader who starts with this impression is then left wondering 
where the properties not found in the Infoset came from (for example, 
the document-uri property of the document node).

In addition, it would be helpful to specify your general conventions for 
nodes here at the beginning. For example, each node consists of a list 
of named properties. In the Infoset, a property may be "unknown" or "no 
value", but in this specification, those values are not used, and 
instead you say a property may be "empty", even if it is not a collection.

Suggestion: The Data Model document might be well advised to include an 
appendix describing the relationships between Data Model properties and 
the Infoset information items and the PSVI, just as the XPath 1.0 spec 
did for its data model

(We are aware of the Processing Model work and its relationship to this 
comment).

*Data Model, Section 4.2.1* says /"Document nodes and XPath 1.0 root 
nodes are essentially identical."/
If these terms are identical, why invent another term ?
If they are not identical, it would be good to have some indication of 
the differences here.
And if we must have another term, why call it a "document node" ? This 
will naturally be confused with the "document element", which in XPath 
1.0 is the child of the root node.

*Data Model, Section 3.3* /"The data model supports incompletely 
validated documents, but inconsistent data models are forbidden."/
The two occurrences of "data model" in this sentence presumably refer to 
different notions. The first is "THE data model", ie, the subject of 
this specification. I don't know what the second "data model" is 
referring to, since presumably this specification is taking pains to 
insure that it is not inconsistent. My best guess is that the second 
"data model" is referring to an instance of the data model.
Assuming we reword the sentence as "...inconsistent instances of the 
data model are forbidden", we are left with the question of defining 
what makes an instance "inconsistent". Perhaps what is meant is that the 
remainder of the specification contains constraints on the data model, 
and instances are forbidden to violate those constraints. Also, since 
the constraints of XML 1.0 do not necessarily apply (see the note at the 
end of section 4.2.4 "Data model to infoset mapping", which says that 
the document information item is not necessarily valid), we can not just 
assume that the collection of constraints that do apply are obvious; 
there needs to be explicit statement of what the constraints are.

Note: see also

http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0104.html

*Data Model, Section 4.1.6* says:

/"If the node is an element node with type xs:anyType, then its typed 
value is equal to its string value, as an instance of xdt:untypedAtomic."/

But *Data Model, Section 4.3.2* says: /"If the element node's type is 
xs:anyType, the dm:typed-value accessor returns the node's string value 
as xs:anySimpleType"/

This seems to be contradictory.

*Data Model, Section 3.4*
What is the namespace for an anonymous type name ?
Can it be the result of an expression ?
Does it need to come from a schema ?
What is legal in an anonymous type name ?

Michael Rys addressed this question in

http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0305.html 
<http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0291.html> 
by saying that "Since the name is not exposed and thus the format used 
by an implementation not testable, any such definition would be vacuous 
and not testable or enforceable."

So, is it the Working Groups position that there are no rules at all 
governing anonymous type names ? If so, please add text to that effect.

*Data Model, Section 3.3* /"Schema-validated documents include documents 
in which some elements or attributes have been validated by "lax" or 
"skip" validation."/

This sentence probably means "a document is considered to be 
Schema-validated if it has been validated against a Schema even if, as 
part of that validation, some elements or attributes have been validated 
by 'lax' or 'skip' validation".
But it can be read as "if a document has had one element validated using 
'skip' validation, then that's sufficient for it be treated as a 
'Schema-validated document' ".

*
Data Model, Section 3.3* What are "Purely synthetic data model instances" ?

*Data Model, Section 4.1.7* "xs:QName" has the wrong font.

*Data Model, Section 4.4.2* refers to "xs:untypedAtomic". This should 
read "xdt:untypedAtomic".

*Data Model, Section 4.1.2* If a fragment is a node (as implied by *Data 
Model, Section 3.3* ), we need a node kind for it here.

*Data Model, Section 4.3.1* should mention that a child cannot be the 
child of any other node (of more than one node).

*Data Model, Section 4.3.1* /" attributes of an element must have 
distinct names"/ should say "distinct QNames"

*Data Model, Section 5* says:

/"The typed value of nodes whose type is unknown (for instance because 
they have not been validated) are labeled with the type xs:anySimpleType."/

This should say "... labeled with the type xs:anySimpleType or 
xs:anyType" to be consistent with *Data Model, Section 3.4 6th paragraph*

[cf http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0235.html]

The Data Model specification refers to several namespaces by prefixes 
(xs:, xsi:, xdt:) that are commonly associated with those namespaces.
Please provide a reference to the specifications where these namespaces 
are defined, preferably early in the Data Model document.

The term "fragment" is used inconsistently throughout the Data Model 
specification, appearing sometimes in the phrases "document fragment" 
and "data model fragment".

The authoritative definition appears to be in section 4 "Nodes", second 
para:
"A tree whose root node is some other kind of node [ie, not a document 
node] is referred to as a fragment".
In view of this definition, the term "document fragment" appears to be 
an oxymoron.

The phrase "data model fragment" appears to be used to mean something 
more general than this definition of "fragment".
For example, Appendix A, "XML Information Set Conformance" first para:
"The following information items must be exposed by the infoset producer 
to construct a data model fragment:...".
In point of fact, the listed information items are equally necessary to 
support documents and not just fragments (note the definition says that 
fragments and documents are mutually exclusive, not that fragments are a 
superset including documents).

[Note: cf http://lists.w3.org/Archives/Public/public-qt-comments/2003May/0032.html]

*
Data Model, Section 1. Introduction* Second para, last sentence:
"A language is closed ... if the value of every expression in a 
language...".
The second occurrence of "language" is meant to refer back to the first 
occurrence.
Suggested solution: change the second "a language" to either "the 
language" or "that language".
Alternatively, you can replace the first occurrence of "a language" by 
"a language L" and replace the second occurrence by "L".

*Data Model, Section 1. Introduction* this paragraph distinguishes 
"value" from "data model".
But the remainder of the specification does not continue to maintain 
this distinction.
I have found the following terms used as synonyms for "value":
"data model", "data model fragment".

*Data Model, Section 3.2 Document order*
Assuming that the term 'stable' means 'stable for the life of the 
query', it is not clear that there is any requirement that namespace 
declarations must always appear in the same order, or that attributes of 
an element must always appear in the same order. For documents that are 
dynamically generated, this requirement may be burdensome.

*Data Model, Section 3.2 Document order* First para, last sentence 
"There is precisely one document order and it satisfies the following 
constraints...". The preceding definition defines "a document order". 
Note the article "a", implying that there can be more than one. Indeed, 
the constraints acknowledge that there is more than one way to order 
namespace declarations or attributes. So what does "there is precisely 
one document order" mean ?

Perhaps you mean "For a particular implementation of this data model, 
and for each document considered by that implementation, there is 
precisely one document order..."

*Data Model, Section 3.2 Document order*
The definition defines "document order" for all nodes in a document, but 
the same notion of order is intended to apply to all trees, including 
fragments.
This is seen, for example, in section 4.1.8 "children Accessor", where 
it says that "For document and element nodes, it returns the nodes that 
are children of that node in document order". An element in a fragment 
needs to have its children ordered, but the definition of "document 
order" does not currently cover this case since "document order" only 
applies to documents.

One solution would be to change the term from "document order" to "tree 
order". However, the term "document order" seems pretty well entrenched, 
so perhaps a better solution is to keep the term but make it apply to 
all trees, not just documents.

*
Data Model, Section 3.2 Document order*
Is this section about "document order" or is it actually about "order of 
nodes" whether they are in the same document or not?
The title says it is about "document order", and the only definition in 
this section is called "document order", but the last two paragraphs 
broaden the discussion to include order of nodes in multiple documents, 
or not in a document at all.

Suggested solution: change the title to "Node order" or something similar.