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.

*Data Model, Section 3.2 Document order*
The first paragraph says that a document order is total.
The last two paragraphs broaden the discussion to include order between 
nodes in different documents, or not in a document at all.
Is it intended that the ordering in the latter two paragraphs is total? 
Or could a conforming implementation simply say, "I choose not to define 
an ordering between nodes in different documents, or between nodes not 
in any document. My ordering of these things is the trivial ordering, 
the one which such things simply have no ordering."?

Put another way, is there anything that breaks if an implementation is 
not able to place a collection of free-standing nodes into a stable order?

*Data Model, Section 3.3 XML Schemas and the XML Information Set*
third paragraph, second sentence: "XML documents that are not well 
formed are not XML".
In that case, how can you begin the sentence by calling them XML 
documents? That's like saying "Chickens that are not birds are not 
chickens" - the sentence is self-contradictory.

Proposed solution: delete the first occurrence of "XML".

*Data Model, Section 3.3 XML Schemas and the XML Information Set*
fifth para, third sentence: "The data model also supports values that 
are not nodes. Examples of these are atomic values,...".
The terms "node" and "atomic value" have not been defined.
Section 3.1 "Node identity" says that XML documents are tree-structured, 
and consist of "nodes" but does not define what these nodes are.
The term "text node" is in common use regarding XML, referring to a 
maximal sequence of consecutive character information items that are 
children of an element.
Section 4 "Nodes" does define nodes, and specifically mentions text 
nodes. But a "text node" looks like an "atomic value", so we seem to 
have a contradiction at this point, because it says that an "atomic 
value" is an example of a "value" that is not a "node".

To fix this:
1. Section 3.1 "node identity", first para, should state that nodes are 
defined in Section 4, "Nodes".
2. "Atomic value" is defined in section 5; add a forward reference to 
that definition here to eliminate the suspicion that a "text node" is an 
"atomic value".

*Data Model, Section 3.6 Mapping PSV Infoset additions to Types*
sixth para, second word: why is "type" italicized? You are not defining 
the term, and I don't think you are trying to emphasize it either.

*Data Model, Section 4.1.4 parent Accessor*
In the Infoset recommendation, the element information item EII 
containing an attribute information item AII is not referred to as the 
"parent" of AII; instead, there is the [owner element] property which 
may be traversed to go from AII to EII. Based on this, it is not clear 
in this specification whether EII is the 'parent' of AII or not.

The first two paragraphs of Section 4 "Nodes" do not resolve this. 
Section 3.1 "Node identity" does say that you assume all the 
"conventional terminology for trees". This might be construed to mean 
that EII is the parent of AII, but then there is the precedent of the 
Infoset recommendation that it is not. On the other hand, 4.3.1 
"Overview" item 10 says "If an attribute node A has a parent element 
E..." which indicates that attributes do have a 'parent' rather than an 
'owner element', and 4.4.2 "Accessors" defines that dm:parent of an 
attribute returns "the parent element node".

*Data Model, Section 4.1.1 base-uri Accessor*
third para: "If the base URI property ... is non-empty"
The Infoset recommendation does not have a notion of a property being 
"empty" or "non-empty".
It does have the notion of a property being "unknown" or "no value". The 
Infoset recommendation says that "unknown" and "no value" are different 
values, but it does not indicate whether the value of a [base URI] 
property may be either these values or just one of them. Anyway, you 
probably mean these values when you say "empty".

Does "empty" mean "unknown" or "no value" ?
If so, it may be better to use the terminology in the Infoset 
recommendation.

*Data Model, Section 4.2.1 Overview*
The property names are not enclosed in square brackets, as is the 
convention in the Infoset recommendation and also in XML Schema Part 1.

Is there some reason for this ?

*Data Model, Section 4. Nodes*
The second paragraph introduces the notion of "tree". The relationship 
between "trees" and "sequences" (introduced in section 1 "Introduction") 
is not clear.
Specifically, can a tree be a member of a sequence?

Our understanding is: a data set consists of a set of nodes and atomic 
values. The nodes are organized into trees. The most familiar example of 
a tree is an XML document; however, other trees are permitted. Atomic 
values never participate in trees.

*Data Model, Section 4.2.1 Overview*
The document-uri property does not correspond to anything in the Infoset 
recommendation or the XML Schema Part 1 recommendation.

What is it?

*Data Model, Section 4.2.1 Overview*
The children and unparsed-entities properties are collections and may be 
empty.
The base-URI is not a collection.
According to the Infoset recommendation, it may be "unknown" or "no 
value" but not "empty".

*Data Model, Section 4.2.1 Overview*
Following the numbered list with 7 items, it says "the children of the 
document node must not be empty".
This sentence is ambiguous.
It could mean "The [children] property of the document information item 
may not be empty" or it may mean "Each child of the document node may 
not be empty (ie, each child must have children of its own)."
This shows two things:
1. It is good to have special notation, such as the square brackets, to 
mark properties, especially when the name of the property is plural.
2. It is good to write universal quantifiers in the singular ("each 
child") rather than the plural ("the children").

Also, we read "the children of the document node must not be empty and 
consist exclusively of element nodes, etc."
This is ambiguous: does it mean "must not be empty and must not 
consist..." or does it mean "must not be empty and must consist..."

*Data Model, Section 4.2.4 Data model to infoset mapping*
There should be a specification of how to use the unparsed-entities 
property of the document node to create the [unparsed entities] property 
of the document information item.

*Data Model, Section 4.2.3 PSVI to data model mapping*
The mapping does not say how to set all properties of the document node.
What are the values of the unparsed-entities and document-uri properties 
of the document node?

*Data Model, Section 4.3.4 Data Model to Infoset Mapping*
The mapping to the [attributes], [in-scope namespaces] and [namespace 
attributes] properties says to create sequences.
However, these properties in the Infoset are unordered sets.

*Data Model, Section 4.3.3 PSVI to data model mapping*
The mapping to the nilled attribute seems to assume that only 
xsi:nil='true' is permitted by XML Schema Part 1.
XML Schema Part 1, section 3.2.7, second box, says that the xsi:nil 
attribute is type boolean, meaning that its value may be 'false'. Thus 
the mere presence of an xsi:nil attribute does not insure that the 
element has been nilled; you also need to look at the attribute value.

*Data Model, Section 4.3.3 PSVI to data model mapping*
First bullet under the children property: it says that the order of 
nodes is implementation-defined. Granted that the character nodes will 
be collected into a single text node, should the processing instructions 
and comments retain their relative order?

That is, take the original sequence of [children], delete all the 
character information items, map the remaining information items to 
nodes, retaining the order, and finally insert the text node at an 
implementation-defined point in the sequence of nodes.

*Data Model, Section 4.3.4 Data Model to Infoset Mapping*
In the mapping to the [children] attribute, the final clause does not 
make sense:
"and that sequence of information items is used as the value for the 
[namespace name] property".

*Data Model, Section 5. Atomic values*
The bullets in the middle of this section would be better expressed in 
the singular,
eg, "The value of a node whose type is an XML Schema primitive type ... 
is represented as an atomic value of that type".
In general, when you have implicit universal quantification, it is a 
better practice to use the singular because it avoids ambiguity.

*Data Model, Section 4.3.4 Data Model to Infoset Mapping*
The mapping to the [children] attribute is described as creating a 
"sequence".
However, the term "sequence" has a reserved meaning in this specification.
It would be better to say that the result is an "ordered list", the term 
found in the Infoset recommendation.

In addition, it should be made explicit that this mapping preserves order.

These are the XML Core “editorial” comments:

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

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.

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.

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.

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.

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.

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?

This section uses a different format for describing its mappings than 
the next section, 4.2.4, Data Model to Infoset mapping.

This section lists each target property in bold with an indented 
paragraph describing how to compute the target property, whereas section 
4.2.4 arranges the information in a table.

The tabular form seems better, chiefly because the column headings 
"Property" and "value" are of value.

Glancing over the other node types, it appears that you have been 
consistent in this convention, but we would prefer to simply have a 
table for the mappings in either direction.

*Data Model, Section 4.2.4 Data model to Infoset mapping*

The result of the mapping is supposed to be an instance of the Infoset 
specification. It says that the [children] property in this Infoset is a 
'sequence'.
But 'sequence' is a term reserved for an XQuery data model instance, not 
a term for something that occurs in an Infoset.
The correct term in the world of Infosets is 'ordered list'.

See also dm-mappings-sequence, 
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0273.html

*Data Model, Section 4.3.1 Overview*

Point 9 says that attributes are not children of their parents.
Shouldn't this also say that namespaces are not children of their parents?

More generally, the use of "parent" for what the Infoset calls "owner 
element" is probably a mistake.
It is unduly confusing to say that something is not a child of its parent !

*Data Model, Section 4.3.1 Overview*

Point 10 says that if an attribute A has parent element E, then A must 
be an attribute of E.
Shouldn't this also say that if namespace N has parent element E, then N 
must be a namespace of E?

*Data Model, Section 4.3.2 Accessors*

It says "The accessors dm:namespaces and dm:attributes return the same 
set of namespace and attribute nodes (respectively) associated with the 
element. They are not constrained to return them in any particular order."
 From this one might conclude that these accessors might return nodes in 
different orders on different invocations.
But Section 3.2 maintains that there is a stable (though 
implementation-defined) order of namespace nodes and attribute nodes.

If these accessors are not bound by that order, does it really make 
sense to say that these nodes are ordered? Probably what is meant by 
this sentence is "These accessors return nodes in document order, which 
is stable but implementation-defined" instead of saying there are no 
constraints on the order at all.

*Data Model, Section 4.4.3 PSVI to Data Model mapping*

Under 'string-value' it says "The [schema normalized value] PSVI 
property if that exists, or the [normalized value] property." 
"Otherwise" would be better to use instead of "or", which implies that 
either one is acceptable.

*Data Model, Section 4.6.1 Overview*

In the middle of this section it says "Namespace nodes must satisfy the 
following constraints". Presumably what is meant is "Processing 
instruction nodes must satisfy the following constraints".

*Data Model, Section Appendix A, XML Information Set Conformance*

First para, second sentence uses the undefined term "data model 
fragment". The term "fragment" is defined. However, "fragment" is 
defined to exclude XML documents, and I believe that the material in 
this list is intended to apply to XML documents as well as fragments.
The encompassing term appears to be "tree". See section 4 "Nodes" second 
para.

(If we do away with the term "fragment" as suggested in
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0287.html
presumably it will be replaced here by "tree" ?)

*Data Model, Section 4.1 Accessors*

Suggestion: add a dm:owner accessor, defined for attributes and 
namespace nodes.

This allows dm:parent and dm:children to symmetrical.

See also 
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0263.html
See also * 
*http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0384.html

*Data Model, Section 4.1.5 string-value Accessor*

If there are no text nodes in the subtree, is the result an empty 
sequence or a sequence with an empty string ?

*Data Model, Section 4.1.6 typed-value Accessor*

Should the return type for a comment node be xs:string rather than 
xdt:untypedAtomic ?

*Data Model, Section 4.1.6 typed-value Accessor*

Should the return type for a namespace node be xs:uri rather than 
xdt:untypedAtomic ?

The DOM WG appreciates the value of the infoset mapping of the model
and the work involved in refining it.  The DOM WG still finds it
unfortunate that the XPDM2 cannot rely primarily on an infoset mapping
(See original issue 1a Different Data Models in W3C).  Issues be
avoided, and there could be other mismatches we have missed in our
reading of your latest revision.

In XPDM2 4.3.4, [namespace attributes] are returned as "the sequence of
namespace information items constructed from the nodes that are
present in the difference between the sequence of nodes returned by the
dm:namespaces accessor on this
element and the sequence of nodes returned by the dm:namespaces accessor of this
element's dm:parent".

But [namespace attributes] is information which was not accounted for
in XPDM2.  Claiming that this information is always the delta
seems inaccurate and causes problems.  If, for example, the data
model is built on a model such as DOM which preserves this information,
this would seem to force a processor to ignore the more-accurate
available information and rely on false information.  This means
that DOM and XPDM2 cannot be seen as views of a single unified data
model and may make it quite difficult to produce functions which rely
on this information which XPath has lost.

For example, let's say the environment containing the XPath
implementation contains a function which verifies a digital signature
on a subtree, returning a boolean.  In terms of XPath, it is
impossible to detect whether the signature is correct or not, because
the signature is different depending upon exactly where the declaration
is in the infoset, between cases which produce identical XPath
data.  The function could gather the rest of the information
missing from DOM or some other more-complete infoset representation,
but XPath's declaration that it possesses the infoset information which
turns out to be flawed confuses and seems to hide the real accurate
information that may be required by other infoset operations.

This is a problem seen in other cases in XPDM2, where inaccurate
information is used in the mapping to cover for information not carried
by XPDM2.  The infoset mapping should not claim to posses this
infoset information which it does not which interferes if the actual
information is present.

Also in In XPDM2 4.3.4, [namespace attributes] description cited above
claims that is constructed as a sequence of [namespace] information
items.  This is not possible because a sequence of [namespace]
information items is not at all the same thing as [namespace
attributes].

In XPDM2 4.3.4, it is not clear whether the namespace information is
even available as namespace nodes, since that is an optional
presentation of namespace information in XPDM2, which may otherwise be
available via accessors.

When dealing with id/idref, XPDM2 exposes xml schema types, when in
fact these are dtd types. See: http://www.w3.org/TR/xmlschema-2/#ID

See also http://www.w3.org/TR/query-datamodel/#PSVI2Types

XML 1.0: http://www.w3.org/TR/REC-xml#id

If the [attribute type] property exists and has one of the following
values: ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, or NMTOKENS, the
{target namespace} is "http://www.w3.org/2001/XMLSchema" and the
{name} is the [attribute type].

id is different defined in xml schema (ncname) than in dtd (name).
They are mixing the two

the target namespace should be dtd instead of xmlschema

In XPDM 4.6.4, [element content whitespace] is purported to be
false. This is another case like shown in issue DOM2, where there
might be a more-complete infoset available which knows the real value
of this information and make it available to various functions, rather
than forcing the infoset value to be inaccurate.

XPDM2 is often not just an extension of the infoset, but a
relaxation.  A mapping is provided, but no information about what
happens to the mapping when the model conflicts with the infoset. 
These issues have been raised before.  For example, what is the
infoset mapping when there are more than one element child nodes of the
document node?  This needs to be clearly specified.  DOM,
does not permit this particular violation of infoset.  An XPath
implementation on top of DOM would not be able to represent this sort
of infoset violation.  This may be true wherever the data model is
more relaxed from the infoset.  In any cases where DOM does not
rigorously guarantee a valid infoset, it reconciles deviations during
serialization or normalization in a specified way.  XPDM2 does not
seem to do this.    We need some sort of fix in the
XPath specification, if only to be able to easily refer to
this sort of infoset relaxation and the inability of some
implementations to represent it (as well as the inability of such a
model to be serialized as well-formed XML).

The DOM API has used a nodeName accessor since level 1 which was
further refined as namespace support was incorporated in level 2. 
The XPDM2 specification seems to have a dm:node-name accessor which
behaves quite differently from the DOM accessor.  We believe that
either the value / behavior should match, or a different name should be
used to avoid conflict and confusion.

Both specs appear to need a conformance section. Here is a thought in
that direction. Functions and operators defines "must" and "may" in
Terminology, and this is fine. I am more worried about the data model.
It should say:
     The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD",
     "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].
(from http://www.ietf.org/rfc/rfc2119.txt) or, it should say what
definitions are being used (e.g., dictionary definitions). It could
also say why the RFC is not used. See the W3C Manual of Style for a
markup suggestion (http://www.w3.org/2001/06/manual/#RFCs).

At .99MB the functions and operators file is too large. It took more
than a minute to load in Mac IE OS 9 and gave a read/write error trying
to save the file to disk. I suggest breaking the spec into chapters,
and then providing a single file (for print, for clicking within the
document and for searching).

Running the data model through Tidy with indent off would save 80-90k,
or over 25%. For functions and operators, this Tidy setting saves 290k,
again over 25%.

Functions and operators seems to be using an old XMLspec stylesheet.
This CSS rule was removed in August 2002 because of rendering problems
(section F1 and some of the definitions are tough to read in Mac IE;
screen shot on request). I suggest upgrading to a later XSLT.
     dt.label       { display: run-in; }

For both drafts, the title of a reference should be the link. For
example:
     <dd>World Wide Web Consortium, <em>Namespaces in XML</em> See <a
     href="http://www.w3.org/TR/REC-xml-names/"
     >http://www.w3.org/TR/REC-xml-names>.</dd>
becomes something like this:
     <dd>World Wide Web Consortium, <cite><a
     href="http://www.w3.org/TR/REC-xml-names/">Namespaces in
     XML</a></cite> on-line at http://www.w3.org/TR/REC-xml-names.>

The Manual of Style shows details for references markup
(http://www.w3.org/2001/06/manual/#References).

Generally, white space is two words. This applies to both drafts (see
http://www.w3.org/TR/REC-xml#sec-common-syn).

In section D of the data model, the green #00CB9C class .element is
dark with black text. #85e9b1 instead (I am sure you can do better than
my color picking) would give some contrast.

[1] http://www.w3.org/TR/2003/WD-xpath-datamodel-20030502/
[2] http://www.w3.org/TR/2003/WD-xpath-functions-20030502/

Missing version property on document nodes
------------------------------------------
[4.2.1] says that Document nodes have only base-uri, children, 
unparsed-entities and document-uri properties.  But there is at 
least one function in F&O which will behave differently depending 
on the XML version (fn:codepoints-to-string raises an error if a 
code point is not a "legal XML character").  Therefore it would 
seem that documents also need a version property reflecting the 
infoset one.

Below please find the I18N WGs comments on your last call document
"XQuery 1.0 and XPath 2.0 Data Model"
(http://www.w3.org/TR/2003/WD-xpath-datamodel-20030502/).

Please note the following:
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- All i18n-relevant comments are marked with ***. There are also general
   comments on the spec which we hope you will find useful.
- We have not yet reviewed the other documents, such as XQuery 1.0
   or XSLT 2.0, and so we might be unaware of i18n issues that appear
   in these specs but may have to be traced back to the data model.
   There are also cases where we have identified an i18n issue here,
   but we are not sure exactly what the best solution will be.
- Our comments are numbered in square brackets [nn].

We look forward to further discussion with you.

General:

[1] In general, this is a very extensive and rather boring document.
Where possible, it should be shortened and compacted, to make it
easier to get the relevant points.

[2] There are mappings between the following different things:
- properties of nodes of the data model
- the corresponding accessors
- the mapping from the PSVI (post-schema validation infoset)
   to the properties
- the mapping from accessor output to XML infoset properties
(in the other draft we are reviewing, there are also functions
corresponding to the accessors).

At least one of these could easily be removed (e.g.
the properties or the accessors).

[3] 1. Intro: 'stylesheet or query' should be replaced by 'transform or query'

[4] 2. expanded-QName: Does this allow to handle special cases such as
    XSLT that transforms XSLT, or XQuery that queries XQuery,...?

[5] 3.2 Document order: "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.
    The second sentence sounds like a corollary from the first, but is
    a non sequitur. It could as well be that an implementation decides
    to order first all the first nodes from all the documents, then all
    the second nodes, and so on. If indeed all nodes of one document
    have to be before all nodes of another document, that should be
    said explicitly, and not only as 'in other words'.

[6] 3.3, markup of [Definition]. Using square brackets for indicating
    definitions doesn't look good at all. Also, there should not
    be a period before and after the closing ].

[9] 3.3 "The data model supports incompletely validated documents, but 
inconsistent data models are forbidden."
     What is an inconsistent data model? What actually happens when there
     is such a model? Does an error get thrown?

[10] 3.4 "In either case, the type names must also appear in the In-scope 
Schema Definitions (as defined in [XPath 2.0]) available to the processor."
     'type name' or rather 'type definitions' or 'types'? There are
     anonymous type names, but it seems strange to say that these appear 
somewhere.

[13] 3.6.1, editorial: "Lexical representations that do not have a timezone 
are assumed to be in UTC for the purposes of normalization." ->
    "Lexical representations that do not have a timezone are assumed to be 
in UTC for the purposes of normalization ONLY."

[14] 4.1.6 typed-value: It would be good to have some explanation of what
     the idea/purpose of this accessor is. It seems to be strange that
     some cases produce errors. Why does mixed content produce a string,
     but complex content, a subset of mixed content, produce an error?

[15] *** 4.1.8 children Accessor: "The sequence of children will never 
contain adjacent text nodes." (see also 4.2.1)
     It is good that text nodes are always merged. But this should
     be stated as a property of the data model, not just mentioned
     in an accessor description.

4.2.1 "The children must consist exclusively of element, processing 
instruction, comment, and text nodes if it is not empty. Attribute, 
namespace, and document nodes can never appear as children"
     [16] - 'if it is not empty' seems irrelevant, obviously an empty document
       won't contain any nodes of other types either.
     [17] - There should be a period at the end

[18] 4.2.1, "Implementations that support DTD processing and access to the 
unparsed entity accessors, use the unparsed-entities property to associate 
information about an unordered collection of unparsed entities with a 
document node."
     spurious comma

[22] *** 4.3.1: processing instructions and comments: Is there a way
     to ignore these (if not in the data model, then in XQuery and XSLT?)
     Because they are not part of the actual text, ignoring them
     is often desirable. In that case, the text nodes should merge
     automatically.

[23] 4.3.2 "If the element node's type is xs:anyType, the 
dm:typed-value  accessor returns the node's string value as 
xs:anySimpleType. If the type is a complex type with complex content, 
invoking dm:typed-value raises an error."
     Doesn't anyType include complex types?

[24] 4.3.2: One additional accessor: Why is this accessor not listed in the 
table?

[25] 4.3.3: Ale xml:base attributes treated as special attributes or like
     namespace declarations?

[26] 4.4.1: "Attribute nodes encapsulate XML attributes": 'represent' may be
     better than 'encapsulate'.

[27] 4.4.2: The details about typed-value are useless duplications. It would
     be better to specify this very clearly in one single place, and
     just point to it from other places.

[28] 4.4.3: "The xs:QName IS computed..."

[29] 4.4.4: [owner element] -> [parent]

[30] ***4.5.1: uri -> anyURI (or an equivalent explanation)

[31] ***4.8.3: "The string-value is not W3C normalized as described in the 
Character Model for the World Wide Web version 1.0 draft."
     This may be misunderstood that the string value has to be
     non-normalized. It should at least be clarified as follows:
     "The string-value is not necessarily W3C normalized as described
      in the Character Model for the World Wide Web version 1.0 draft.
      It is the responsibility of data providers to provide appropriately
      normalized text, and the responsibility of programmers to make
      sure that operations do not de-normalize text."
     Even better clarification, in particular of the first sentence,
     is highly desirable, to clearly say that this refers to a state,
     and not an action.

[32] 5. "The values of nodes whose type is derived by union from an XML 
Schema primitive type are represented by a sequence of atomic values each 
of whose type is one of the individual types from the union. The union type 
information is lost and only the specific types of each individual item is 
retained."
     this seems to apply to lists of unions, or maybe unions of lists,
     but not to simple unions. This should be clarified.

[7] *** 3.3 data model support of values that are not supported
    by the XML Infoset: What about pcdata with an associated
    language information? What about document fragments with
    associated inherited attributes in general? RDF is dealing
    with such things, and it would be very good if they could be handled.

[8] *** The handling of inherited attributes in general is an important
    issue for I18N (because of xml:lang) that wasn't dealt with at
    all in XSLT 1.0. Apart from what may be needed in the data model,
    support is also important on a higher level.

[11] *** anyType, anySimpleType, anyAtomicType, untypedAtomic, string, text 
nodes:
     This is a very general concern, but very important for
     internationalization. There seems to be a proliferation of type
     variants dealing with the simplest of things in XML, namely simple
     text. This seems to ruin quite a bit of the benefits of using
     Unicode; now that we have solved the character encoding problems,
     we don't want to create arbitrary differences for simple pieces of
     text. But various specs (e.g. also RDF) seem to come up with
     additional ways of creating arbitrary differences.
     anyAtomicType and untypedAtomic seem to be badly explained
     and justified. We have to make sure that whenever possible, there
     is no arbitary boundaries in functionality. Rather than treating
     string, text nodes, and untyped as three completely different
     things, they should work as much as possible in an overloaded
     way similar to the number operators.

[12] *** 3.6.1 date and time mappings: for things with timezones, 
canonicalizing
     the time zone and then representing the original time zone separately
     seems to make sense. But for values without a timezone, representing
     them as if they were in UTC is inherently wrong and will lead to
     a lot of misunderstandings. (having things with timezones and things
     without timezones as separate types would have been the better
     solution originally, and maybe it's still not too late for that)

[19] 4.2.2 typed-value: why does document return the string value, but
    any of its elements could return an error?

[20] *** 4.2.2 and many other places: As far as we understand from previous
    discussions, xs:string is often used instead of xs:anyURI for
    convenience (to avoid additional casts). It is important in these
    cases to clearly state that the values actually have to be anyURIs,
    AND are treated according to anyURI syntax.

[21] *** 4.2.4: [character encoding scheme]: "The values of these 
properties are implementation-defined but must be consistent with the rest 
of the Infoset constructed."
     What does 'consistent' mean here? There is a dependency between
     non-ASCII element/attribute/... names and the encoding chosen.
     But for a data model that produces an infoset that is (not yet)
     intended for serialization, it almost seems that any specific
     value would be inappropriate. On the other hand, when actually
     being written out, at least for XSLT, the property is not
     implementation-dependent, but determined by the <output>
     element. So we suggest the following text:
     "irrelevant during processing, determined by XQuery or XSLT
     for output"

[33] 5. "Using the canonical lexical representation for atomic values may 
not always be compatible with XPath 1.0.": Please say when this is not the 
case.

D. Example:
     [34] *** xml:lang should be used in the instance, not only appear
       in the schema (and in the schema be allowed higher-up so
       that it can be inherited)

     [35] *** Defining a default currency in the schema is bad design
       practice. Without the schema, the data is basically useless.
       Please choose something different for an example of default attribute
       handling.

     [36] *** The monetaryAmount type works well for some currencies
       (USD, EUR,...), but does not work for others (Yen,...).
       Please generalize. The number of fractional digits needed
       currently is 0, 2, or 3.
       for details, please see:
http://www.bsi-global.com/Technical+Information/Publications/_Publications/t 
ig90x.doc

     [37] *** The pop-culture example may make it difficult for non-native
       readers to understand the example, or to create a reasonable
       translation.

     [38] - "Literal strings are shown without the xs:string() constructor"
       this should say that strings are shown in quotes

     [39] - Why are N1-N5 before P1 and E1?

     [40] - A4: why is typed-value xs:token?

     [41] - typed-value of E5: inconsistent.

     [42] - other inconsistencies include: children(E5)->T2,
       string-value(A7), (A8), (A9), (A10), (A11) (string and typed
       values seem out of sync)

     [43] - Graphic representation of the data model. [large view]: This
       should be provided in SVG

An initial batch of notes from XML Schema on XQuery, the data
model, and functions and operators is on the Web at
http://www.w3.org/XML/Group/2003/07/xmlschema-query-notes.html

[This comment is a place-holder for editorial comments]

2.1. Time zones

    The [24]query data model construes timezones as significant in the
    value as well as the lexical forms of xs:dateTime, xs:date, and
    xs:time. The XML Schema specification does not forbid applications to
    take timezone information into account; the timezone information is
    visible in the lexical forms of the post-schema-validation information
    set. That said, however, the data model's value space for this type is
    definitely not XML Schema's value space, and the situation is at best
    confusing for users.
    We believe that the discrepancy between the XML Query and XML Schema
    accounts of these types is untenable, because it will place an
    unacceptable burden on users of the two languages. As a Working Group,
    we oppose the progression of the Query/XSL specifications while this
    discrepancy persists.
    We believe the three Working Groups must discuss this and related
    questions and reach consensus, and changes must be made either in one
    of the two type systems or the other, or in both. We are willing to
    make appropriate changes in XML Schema 1.1 to achieve this
    harmonization if together we reach consensus that that is what is
    needed.
    It may be noted that some members of the Schema WG favored including
    the timezone in a valuespace tuple in the first place. Others believe
    that there is a serious problem with any evaluation mechanism which
    does not realize that "5 p.m. Eastern Time" and "2 p.m. Pacific Time"
    are different ways of denoting the same moment of time.

      [24] http://www.w3.org/TR/xpath-datamodel/#timezones

2.2. The type anyAtomicType

    A type named anyAtomicType is introduced as a subtype of
    xdt:anySimpleType; the new type is introduced as an ancestor to
    builtins such as xs:integer. We have some concerns here; they include:
    (a) this changes the type hierarchy and is incompatible with the
    simple types as published in XML Schema (because those types
    explicitly name their base types), and (b) the derivation of
    anyAtomicType appears to be `magic' and thus outside the scope of
    derivations expressible in XML Schema 1.0. Several members of the
    Schema WG believe that does seem to be real need for this type in
    Query, but it appears to us that some coordination is needed among the
    responsible Working Groups.
    Changes of this kind to the type hierarchy create clear
    interoperability problems because different schema-aware processors
    will produce different and incompatible results when asked for
    information about xs:integer or other primitive types. Because this
    type as defined is necessarily magic, the problems cannot be resolved
    by providing a conventional declaration for it. The XML Schema Working
    Group opposes the progression of any Query/XSL-related specification
    until this incompatibility has been resolved.
    As with other discrepancies between our type system and your use of
    it, we are ready to modify our type hierarchy in XML Schema 1.1 if the
    responsible Working Groups can reach consensus.

2.3. The type untypedAtomic

    The type xdt:untypedAtomic is introduced for untyped nodes "such as
    text in schemaless documents." The query LC draft says "It has no
    subtypes". It's not clear whether this type is ever to be used by
    schema processing, or is only visible in the query system. We believe
    this raises compatibility issues vis-a-vis XML Schema. It might be
    argued that versions of XML Schema should assign this type in the PSVI
    to information items which current receive no type information
    properties (e.g. because they matched a wildcard with
    processContents="skip"), as that would seem to maximize compatibility
    with Query.
    We believe the three Working Groups should work to achieve consensus
    on this topic. We believe you should not progress your documents until
    we do so.

2.6. Plans for CR/PR/REC

Comments on Data Model document dated May 2, 2003:
...

In Section 3.6, when the [validity] property does not exist, it means this
document has not been yet validated. Earlier in the document, it is said 
that
data model also allows invalid documents. What happens when [validity] 
property
exists, and is "invalid" ?

In Section 4.1.6, it is confusing to have three different type rules for 
element nodes
with complex type. These rules prevent possible use of any index as they 
would require
a full document scan. This creates a potential performance problem.
As the language already provides a string() function, I think the typed 
value of 
all element nodes with complex type should be a type error.

In the table in Section 4.5.4, the description for the value of [prefix] 
refers
to an appropriate namespace prefix, which is defined "below", but no such 
description
exists in this section.

In Section 4.7.2, what is the data type of the return of dm:typed-value 
for a comment 
node? dm:unTypedAtomic?

The section D Example should include a comment. Given the difficulties 
with dateTime, perhaps one or two of those could be thrown in?  I also 
didn't find any examples of the dm:element-declaration() accessor.