XQuery 1.0 and XPath 2.0 Data Model

Here are the comments from the DOM Working Group regarding the
XQuery/XPath Data Model document [1].

While no other specification, including the specification of XML syntax,
will perfectly match the W3C XML Information Set (Infoset) in all
aspects, the Infoset seems essential as a yardstick to see where
specifications may fail to interoperate properly when exchanging XML
information. In the latest version of DOM Level 3 Core, the DOM working
group has included a mapping between the Infoset and the information in
a DOM tree to be sure there is no confusion, as Infoset continues to be
the standard way of describing various types of standardized
representations of XML content. Note that this mapping between the DOM
model and the Infoset is done in a separate appendix in the
specification, and did not necessitate a complete rewriting of the DOM
specifications. The DOM WG has supported the development of the Infoset
to provides a set of definitions for use in W3C specifications that need
to refer to the information in an XML document.

Some DOM information items have been excluded from the Infoset, with the
understanding that Infoset definitions are most useful for XML
information that is common to multiple specifications and the DOM-only
information has not seemed harmful to compatibility between
specifications that did not require that particular information. DOM,
for example, is perhaps the only standard representation of XML (besides
the XML syntax itself) that cares to distinguish between CDATA sections
and regular text, but the ability to distinguish does not hurt the close
correspondance between infoset and DOM. The Infoset has also been
augmented to include a number of additional items used by other
specifications, for which DOM has included support in later versions of
the specification. The Infoset must be a work in progress adding
newly-identified information that needs common definition so that
specifications relying on infoset definitions may be
interoperable. There is no doubt that there are significant new domains
of XML data that require sharing between specifications that would
benefit from Infoset standardization.

DOM will commonly be used to make use of most other specifications at
W3C including XPath, Web Services, XML Schema, HTML, XML, CSS, XML
Signatures, and so on.  It is highly desirable for specifications to be
defined in terms of the Infoset so that the common XML information can
be exchanged as the currency of XML representation, and where
information is lost or mangled by a specification, that is known as
well. The mismatch between the DOM and XPath specifications in the past
has created issues that could have easily been better aligned in a
common model.

The DOM Working Group is very disapointed by the removal of the Infoset
mapping, included in the previous version of the Data Model, despite our
encouragements and praise of the mapping [2]. The intent of our previous
comments was to help the XSL and XML Query groups have an accurate
mapping between their specifications and the Infoset, and certainly not
meant to discourage the XSL and XML Query groups to have such
mapping. Therefore, we would like to object to the absence of _direct_
mapping between the XQuery/XPath Data Model and the Infoset, and
believes the approach taken by the latest specification of the Data
Model is harmful for the future of the XML Architecture. We are still
concerned about our previous comments [2] regarding the discrepancy
between the XQuery/XPath Data Model and the Infoset, and believe those
remain to be addressed.

[1] http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/
[2] http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/att-0003/XPDM2-DOM.html
[3] http://lists.w3.org/Archives/Member/w3c-ac-forum/2000JulSep/0215.html

We’ll add the mapping.

Here are the comments from the DOM Working Group regarding the
XQuery/XPath Data Model document [1].
[…]
Finally, the DOM Working Group reiterates his previous comment (DOM8)
regarding the name conflict between the accessor dm:node-name and the
DOM attribute Node.nodeName. Again, the notion of node names between DOM
and the XQuery/XPath Data Model is significantly different, even if the
XQuery/XPath specification does not call for physical implementation of
the abstract model. A different name (dm:universal-name, or
dm:node-uname, etc.) should be used to avoid conflict and confusion,
such as the ones reported in September 2000 [3].

[1] http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/
[2] http://lists.w3.org/Archives/Public/public-qt-comments/2003Jul/att-0003/XPDM2-DOM.html
[3] http://lists.w3.org/Archives/Member/w3c-ac-forum/2000JulSep/0215.html

Decided at joint telcon 183: reject.

The WG has discussed this issue and decided that no change is
necessary. We note, in particular, that our node-name function is in a
different namespace which is an accepted method for providing globally
unique names. There was no support in the WGs for renaming our
accessor.

We also point out that the node-name function exists in F&O and that
the node-name accessor provides the abstract functionality required for
this user-visible function.

We have observed a welcome trajectory over drafts of the Data Model to
reduce the distance between its core and the W3C Infoset
Recommendation.  We actually see no remaining impediment to completing
this and actually identifying the Data Model explicitly as an
extension of the Infoset.  This would probably need to be done on two
levels: the first, in the spirit of the PSVI, adding new properties
and possibly new information items, the second adding accessors.

Although in one way this might seem to be a purely editorial request,
or at best a rhetorical one, we actually think participating in the
use of the Infoset abstraction in this way will actually make the
Query specs stronger and simpler.

A major advantage of adopting this suggestion, connected to our
previous comment XSCH-QL-018 [1] about 'validate' expressions, is that
the need for serialization in the definition of validation goes away
-- infosets are by definition validatable as such.

Henry Thompson
By and on behalf of the W3C XML Schema WG

We’ll add the mapping.

Data model should support cdata sections. Preserving of cdata in input documents can be
controlled by flag in static context (and declaration in xslt/query prolog).
Without this it would be impossible to preserve structure of document durning transformations.
(it's especially big problem for nearly-identity transformations than changes only small parts of original document).
There are also other uses, such as xpath based search & replace option in XML editors
(ability to find and modify cdata sections) and finer control in XSLT over which content is serialized as cdata.

This will need cdata constructors in XSLT and XQuery, and cdata() SequenceType.
Maybe this feature can wait to V3.0, but will be needed at some point.

Decided at BEA face-to-face: reject.

Thank you for your comment.

You asked that the Data model should support cdata sections.
The XML Query and XSL Working Groups considered this request.

Since CDATA sections are an artifact of input encoding,
they are not reflected in the Data Model, and the comment
was therefore rejected.

SECTION 2: Basics

The language should allow for nested sequences. Nested sequences (a.k.a sequences of sequences) will help in returning a set of related values easily. The current mechanism requires one to put those values inside an XML element which removes node identities, typing etc. 

 Allowing nested sequence in later versions might be quite hard because of implicit rules governing atomization, normalization and concatenation of sequences.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 6.2.4

The description of how the children property of the element node is 
constructed from PSVI indicates that if the [schema normalized value] 
property exists, and the processor chooses to use that means of setting 
the property, the order of nodes in the sequence is implementation 
defined.

This should be phrased to indicate that only the text node will be in some 
implementation-dependent position relative to the PI and comment children, 
but the order of the PI's and comments themselves is the same as in the 
[children] property.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM, not just personally.]

Decided at BEA face-to-face: order will be clarified.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 6.2.2 and 6.3.2

The penultimate bullet in the description of dm:string-value indicates 
that "If the element type is xs:dateTime, xs:date, or xs:time, returns the 
original lexical representation of the typed value, recovered as follows:"

The process described actually sounds as if it is operating on the typed 
value, and the conversion back to a lexical value might not yield the 
original lexical representation - for instance, the three strings 
"2004-01-22T24:00:00+05:00", "2004-01-23T00:00:00+05:00" and 
"2004-01-23T00:00:00.000+05:00" all represent the same xs:dateTime value. 
If this process must yield the original lexical representation, the 
description of the procedure needs to be corrected; otherwise, it should 
make it explicit that the original lexical representation might not 
result.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM, not just personally.]

Decided at BEA face-to-face: fixed.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 3

The second paragraph states that "The data model supports well-formed XML 
documents conforming to [Namespaces in XML]."

The Infoset recommendation errata supports documents conforming to XML 1.1 
and Namespaces in XML 1.1.  If Data Model refers to Infoset, this section 
needs to either include Namespaces 1.1 or be worded more generally. This 
comment applies throughout this section.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM, not just personally.]

Decided at BEA face-to-face: fixed

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 2.5

In the second paragraph, it is unclear how long the implementation-defined 
anonymous type name must persist.  For instance, if the same query or 
transformation is evaluated twice, with the same static context each time, 
must the names used to identify the same anonymous types in each 
evaluation be consistent.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]

Decided at joint telcon 183: added wording to clarify.

SECTION 6.1.3: Construction from an Infoset (of a document node)

A document node has a document-uri property, but these rules do not
tell how to set it. If the document-uri property does not exist in the
Infoset, we should say so, and we should say how it gets into the data
model.

Decided at BEA face-to-face: agreed to clarify.

SECTION 6.5.3: Processing instruction information items

Under "target" it says that the value of the target property in 
the data model is the same as the value of the [target] property
in the Infoset.  However, the Infoset allows an arbitrary Name
for this value (see XML 1.0 section 2.6 rule [17]) which means
that a target can have arbitrarily many colons.  The Namespaces
recommendation did not limit this.  On the other hand, the 
XQuery data model limits targets to NCName (no colons).  What 
happens when a processing instruction containing one or more
colons is loaded into the data model?  This should be specified.
(See also comment re: 6.5.1)

Decided at BEA face-to-face: it’s an error to map a PI whose name is not an NCName.

SECTION 6.5.1: Overview (of processing instructions)

It says that the target property must be an NCName.
XML 1.0 only requires the target to be a Name, ie, permits any
number of colons.  Oddly, Namespaces 1.0 has nothing to say about
the target of processing instructions.  It seems like the target
of a processing instruction should be allowed to be a Name, since
that is the only restriction in XML 1.0 + Namespaces 1.0; or
at least a QName, which would be a restriction in the spirit if
not the letter of Namespaces 1.0.
(see also comment re: 6.5.3)

Decided at BEA face-to-face: it’s an error to map a PI whose name is not an NCName.

SECTION 6.6.3: Comment information item

It says "Although the data model is able to represent comments, 
it may be unnecessary or even onerous for some applications to 
do so. Applications should construct nodes in the data model to 
represent comments. The decision whether or not to represent
comments is considered outside the scope of the data model, 
consequently the data model makes no attempt to control or
identify if any or all comments are ignored."

This paragraph is confusing.  Either "application" is referring
to a program that invokes an XQuery or XPath processor, or
"application" means the XQuery or XPath processor itself.  

In the first interpretation,
it is hard to interpret the sentence "Applications
should construct nodes in the data model to represent comments"
for two reasons: a) it is not the user program's responsibility
to construct nodes at all; nodes are a formalism of the data
model and not necessarily things that the user program knows 
how to construct, aside from invoking the XQuery or XPath 
processor (where is the C or Java library to create a node?)
b) It is not the business of the data model to tell
users how to write their programs anyway.

The second interpretation seems to give the XQuery 
or XPath processor the license to discard comments from the user's
XML data.  Granted the user may want them discarded, but there
are ways he can express that desire, for example, using XPath
expressions that filter out comments.  In addition, if the 
user has explicitly coded a comment constructor in his XQuery
expression, is it really right to disregard the user's stated 
desire to create a comment?  If you really intend that XQuery
support for comments is optional, then it ought to be called out
in the list of optional features (Xquery section 2.6 "Optional
features").

Decided at BEA face-to-face: comments are no longer optional.

SECTION 6.2.2: Accessors (in 6.2 Element nodes)

dm:string-value(): the note about "recovering" the original 
lexical representation of xs:dateTime, xs:date and xs:time 
types hints that the model is that the original lexical
representation can be lost (probably as a result of forming the 
PSVI).  If that is the case, then don't we need to talk about some 
other types as well?  For example, xs:duration.  There are
many equivalent ways to represent a zero duration, such as
P0Y = P0M = P0D = PT0H = PT0M = PT0S.  Given an element of 
simple type xs:duration whose value is the zero duration, 
which of these (or many other candidates) is the string value?
In general many types have more than one lexical representation
for the same value.  Since the model is that the implementaiton
is not required to save the true original lexical representation,
we need rules telling which lexical representation to 
regenerate as the string value.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model: specification too fuzzy

Under which circumstances do the implicit operations
performed during the schema validation like adding default
element and attributes values happen ?

For example, if one element has validation property valid, yet one
of his ancestors is not valid, section 6.2.2 states that the element 
will have
type annotation xdt:untyped.

Are the default attributes and values added to the element or not in 
this case?

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model: inconsistency, major

The Data model takes an inconsistent position with respect of elements
resp. attributes that are labeled with type annotation xdt:untyped,
resp. xdt:untypedAtomic.

In section 6.2.4 it is stated that an element AND all it's ancestors
have to have a validation property "valid" for the element to be
labeled with a Qname different then xdt:untyped.

This would mean that, as a side effect of this definition the
following constraint should hold: if an element has type annotation
xdt:untyped, then all it's descendent elements have also a type
annotation xdt:untyped.

Does this constraint indeed hold ? was this the intent of the
specification ? If yes, please state this constraint explicitly.

On the other hand, other portions of the specification do NOT require
the ancestors to be valid. Section 3.3.1 is one example. Section 6.3.2
that deals with type annotations of attributes seems to be
inconsistent with it since it doesn't look at the validity of the
ancestors. Moreover, the computation of the nillability property also
ignores the validity of ancestors, potentially creating inconsistent
data model instances.

What is the intent here ?

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model: request for simplification

What is the rationale for supporting functionality beyond
the Infoset: e.g. documents with empty content, with multiple
element children, etc ?

Is this rationale serious enough to overcome all the serialization and
application communication difficulties that derive from there ?

If no, please simplify.

/ Michael Rys <mrys@microsoft.com> was heard to say:
| There are outside requirements to support XQuery on a document node that
| may contain more than one element besides XSLT. The SQL-2003 XML
| Datatype follows that model. 
|
| Restricting a document node now would not satisfy their requirements
| either.

In summary:

- XML 1.0 defines external parsed entities which have multiple root elements.
- XSLT 1.0 backwards compatibility requires them.
- SQL-2003 requires them.

I believe this represents compelling evidence in favor of keeping the
existing functionality.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model: inconsistency, request for simplification

Section 2.5. states that anonymous types can have an identifier that
is not a Qname, while this seem to be inconsistent with the rest of the 
document.
(the signature of the type() accessor is always an optional Qname).

We should simplify the data model and request the name of a type (even
anonymous) to be a legal Qname.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model: request for simplification

We would like to simplify the definition of the typed value
as follows.

The typed value of a document should raise an error.
The typed value of a element with complex type with
mixed content should raise an error.
The typed error on a namespace node should raise an error.
The typed value of a processing instruction should raise an error.
The typed value of comment should raise an error.

I do not see the rationale for supporting the cases above. They do not 
bring
any additional expressive power.

The typed value only makes sense for attributes, for elements with
simple content or complex type with simple content and for text nodes.

In general, as a design philosophy, it is preferable to add this kind 
of limitations
in V1. We can always convert an error into a real value in the next 
versions,
but not a wrong kind of value into another value or error later on.

Decided at BEA face-to-face: typed-value is xs:string

Data Model:  specification too fuzzy

The Data Model misses certain consistency constraints that seem
to be required to preserve a data model instance internally consistent.

Examples are:
(a) is it true that if a node has a base uri propery, then all the 
descendants
have the same base-uri property?
(b) is it true that if a node has the nillability property being true, 
then it has
no text  and elements nodes as children, and it has an attribute 
xsi:nil="true"?
(c) if the type annotation of an element is a certain Qname different 
from xdt:untyped
and the element has  an attribute xsi:type, then are the value of the 
attribute and the type
annotation required to be the same ?
(d) etc

If the data model is generated via Infoset or PSVI it is relatively 
clear that those extra constraints
are not violated. The problem is that Data Model instances can be 
generated
directly by applications from other input structures (e.g SQL records, 
COBOL structures) etc.

The concern is that the application generated data model instances 
(other then Infoset and
PSVI) do not have a set of rules and constraints clearly spelled out 
that they will have to satisfy
to create correct data model instances.

Dana's action is completed:
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004May/0037.html

Norm: I'm inclined to incorporate these

Dana: the most interesting constraints aren't in here yet, the ones
about typed values and types and strings, etc. because there's too
much fluctuation.

Norm asks what to do.

Dana suggest leaving it open.

ACTION: Norm to add a note to the issue pointing out that additional
constraints may be desirable and leave the issue open.

ACTION: Incorporate the constraints in the message that completed
Dana's action.

Accepted.

Functions and operators: request for functionality

XQuery's function and operators builtin library should
have enough functions to introspect all the data model
accessors for the nodes. e.g. we should be able to ask for
the nillable property and for the type annotation.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

If an element has a complex type with complex content, the
typed-value() accessor raises a type error when applied to the
element. So if the Cities element has a known type, the following
raises a type error:

  <Cities>
    <City>
        <CityId>01</CityId>
        <Longitude>100</Longitude>
        <Latitude>32</Latitude>
    </City>
    <City>
        <CityId>02</CityId>
        <Longitude>54</Longitude>
        <Latitude>24</Latitude>
    </City>
  </Cities> * 2

If you the same element is placed in a document node, the
typed-value() accessor returns its string value, as an instance
of xdt:untypedAny. Consider the following query.

document {
  <Cities>
    <City>
        <CityId>01</CityId>
        <Longitude>100</Longitude>
        <Latitude>32</Latitude>
    </City>
    <City>
        <CityId>02</CityId>
        <Longitude>54</Longitude>
        <Latitude>24</Latitude>
    </City>
  </Cities>
} * 2

This query succeeds. Either both queries should succeed,
or both should fail.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Section 3.3.1:

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

  If [member type definition] exists:

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

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

and likewise for [type definition].

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Sections 6.2.1, 6.2.2 and 6.3.2:

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

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

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

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Section 6.2.2 and elsewhere:

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

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Section 6.2.4:

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

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

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Section 6.3.2 under "dm:string-value":

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

Accepted editorial suggestions.

Section 6.7.1:

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

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Section 6.7.4:

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

Accepted editorial suggestions.

The rules for dm:typed-value() are confusing and inconsistent for
elements and document nodes. Here is an example that illustrates one
set of problems: what is the result of the following query?

  <Cities>
    <City>
        <CityId>01</CityId>
        <Longitude>100</Longitude>
        <Latitude>32</Latitude>
    </City>
    <City>
        <CityId>02</CityId>
        <Longitude>54</Longitude>
        <Latitude>24</Latitude>
    </City>
  </Cities> * 2

In the current specification, this question can not be answered unless
we know the schema information associated with the Cities
element. Here is the current set of rules:

1. If the element has a known complex type, and it does not allow
mixed content, then it raises a type error.

2. If this element's type is xdt:untypedAny, the typed value of the
element is its string value, as an instance of xdt:untypedAtomic, so
this query evaluates to (2 * 0110032025424). This is surprising, and
it is not useful for users.

3. If this element's type is known, and it allows mixed content, the
typed value of the element is its string value, as an instance of
xdt:untypedAtomic, so this query evaluates to (2 * 0110032025424).

It would be much simpler and cleaner to say that dm:typed-value()
returns an error for any node with child elements. This is
incompatible with the behavior of XPath 1.0, but so is the current
behavior for elements of known complex type.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

(IBM-DM-031) The Data Model document lists namespace nodes as one of the 
seven kinds of node. But a node is needed only to preserve identity and to 
represent a position on an axis. The identity of a namespace node is never 
used, and the namespace axis is deprecated in XPath 2.0 and not supported 
in XQuery. Neither XPath nor XQuery provides a way to construct a 
namespace node independently of an element node. Therefore there is no 
reason to retain the concept of a namespace node in XPath 2.0. It should 
be replaced by the concept of "in-scope namespaces" as a property of an 
element node. The term "in-scope namespaces" is already widely used (13 
times in the Data Model document and 10 times in the Functions and 
Operators document). We should make "in-scope namespaces" one of the 
properties of an element node, supported by two accessors 
(get-namespace-uri-for-prefix() and get-in-scope-prefixes(), which are 
already documented in Functions and Operators). We should leave it up to 
the implementation how to support these accessors. Various strategies are 
possible, including storing all the in-scope prefixes in each element 
node, or only storing the "new" prefixes that are introduced by each node 
(different from its parent). 

Replacing namespace nodes with the existing concept of "in-scope 
namespaces" will shorten and simplify the Data Model document, removing 
various accessors on namespace nodes which XQuery does not provide any way 
to invoke. Implementations that choose to support the (deprecated) 
namespace axis can synthesize "namespace nodes" from the "in-scope 
namespaces" property of an element node. Implementations that do not 
support this deprecated axis need not be aware of namespace nodes at all. 
All references to "namespace nodes" in XPath and XQuery-related documents 
(such as the Serialization document) can be rephrased in terms of the more 
abstract concept of "in-scope namespaces" for an element; this provides 
greater implementation flexibility and in many cases simplifies the 
documents.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

When the conformance section is written, implementations should be
able to claim conformance to the Infoset and PSVI mappings specified
in the data model. Obviously, implementations still need to be able to
create instances of the Data Model however they wish - implementations
that do not use the Infoset or PSVI mappings would be conformant with
XQuery, XPath, and XSLT, but would not conform to these two normative
Data Model mappings. Implementations that do conform to these mappings
would have a higher degree of interoperability.

The Data Model doesn’t have a conformance section; the host language
has to describe conformance.

The following comments are from the XML Schema working group on the Last
Call draft of 12 November 2003 of XQuery 1.0 and XPath 2.0 Data Model. [1]
These comments are in addition to our previous comments recorded in [2]. We
remain interested in the status of those comments.

[1] http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112
[2] http://www.w3.org/XML/Group/2003/08/xmlschema-datamodel-comments

This issue is just the preamble for the issues that follow. Closed.

1. Schema-related issues
1.1 Types in data models
1.1.1 Where are they stored?

In various places, the draft talks about "types" and properties of these
types. (An example is in section 6.2.2 and 6.3.2, for accessor
"dm:string-value".)

It seems that the word "type" in those places refer to schema type
definitions, instead of just their "name"s. But it's not entirely clear how
such type information is available. Element/attribute nodes only have a
"type" property for the NAME of the type, but not the type itself.

It's also not clear from the draft how processors get a handle to these
type definitions (schema components). (From a separate schema loader, from
PSVI, etc.)

It "seems" that the intention is:
- Type definitions are available within DM-compliant processors.
- There is also a name-to-type mapping (including anonymous type names)
that's available in such processors.
- Such information is internal to the DM, and is not exposed to
applications that use the DM. (Which explains why there are no accessors to
expose real types.)
- Schemas (or schema components) are somehow "imported" by DM processors.
How they are imported is not defined in DM spec. Other specs or
implementations can have their own ways to implement such importing.

If the above is correct, then there should be some notes to make it clear.

We believe this is fixed. Norm to ask schema to review.

1.1.2 Light-weight PSVI

If the DM is built on top of a light-weight PSVI, then how does the
"name-to-type" mapping work? For anonymous types, all the information
provided by light-weight PSVI is "this type doesn't have a name". Even if
the DM processor somehow "imported" all the type definitions, how does it
know which type definition corresponds to this anonymous type?

We came to the conclusion that processors *might* be able to map an
anonymous type to a type definition in the "imported" schema (it works by
induction):
- If [type definition anonymous] is true for the validation root, we assume
its type definition is already available to the processor.
- Assume the type definition is known for the parent element. If [type
definition anonymous] is true, then it's possible to find an
element/attribute declaration (hence the type definition) for the current
element/attribute in the type definition of the parent element. (EDC makes
it easier, but wildcards makes it harder.) (Special process is needed for
xsi attributes.)
- Assume the type definition is known for the current element/attribute. If
[member type definition anonymous] is true, then the processor can
re-validate the string value using the type definition to find out which
member type is actually used.

The above process is possible, but it's not straightforward:
- Even with EDC, marching through all particles in the parent complex type
is expensive.
- With wildcards, EDC doesn't always give the right answer. (Imagine a
sequence of a local element "ns:e" with an anonymous type followed by a
wildcard. And there is a global "ns:e" with an anonymous type. In the
instance there are 2 "ns:e" elements. What's the type for the second
"ns:e"?)
- Re-validating strings to get member type definitions is also expensive
(and redundant).

So to get the correct answer, a DM processor has to duplicate *a lot* of
the work that has already been done by the schema processor.

We want to get a clarification about whether the DM spec does expect
implementations to work in the above described way if a DM is built on top
of a light-weight PSVI. (Or there is a much easier way that we are
missing.)

Some members from the schema WG suggest that maybe DM construction should
only work with heavy-weight PSVI.

Decided at BEA face-to-face: added note about lightweight PSVI.

1.2 Anonymous type names

In Section 3.3.1

"If the [validity] property exists and is "valid", the type of an element
or attribute information item is represented by an expanded-QName whose
namespace and local name correspond to the first applicable items in the
following list:
* If [member type definition] exists and its {name} property is present:
  - The {target namespace} and {name} properties of the [member type
definition] property.
* If the [type definition] property exists and its {name} property is
present:
  - The {target namespace} and {name} properties of the [type definition]
property.
* If [member type definition anonymous] exists:
  - If it is false: the [member type definition namespace] and the [member
type definition name].
  - Otherwise, the namespace and local name of the appropriate anonymous
type name.
* If [type definition anonymous] exists:
  - If it is false: the [type definition namespace] and the [type
definition name]
  - Otherwise, the namespace and local name of the appropriate anonymous
type name."

It's related to a previous comment [3].

[3] http://www.w3.org/XML/Group/2003/08/xmlschema-datamodel-comments#d0e205

In the above comment, the schema WG suggested that the rules for [type
definition] should be changed to handle anonymous types. On top of that, we
believe that similar changes need to be applied to the rules for [member
type definition].

Proposed fix: consider something similar to what DOM3 Core spec adopted
[4].

[4] http://www.w3.org/TR/2003/CR-DOM-Level-3-Core-20031107/core.html#TypeInfo

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

1.3 String values of elements and attributes

In section 6.2.2 and 6.3.2, for "dm:string-value".

1.3.1 Lack of consistency

There are umpteen ways to compute a string value,

- dm:string-value [5] of Element Node
- dm:string-value [6] of Attribute Node
- casting an atomic value to xs:string [7]

[5] http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/#ElementNodeAccessors
[6] http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/#AttributeNodeAccessors
[7] http://www.w3.org/TR/2003/WD-xpath-functions-20031112/#casting-to-string

First, umpteen casting/conversion rules are unnecessary. It appears that
[5] and [6] and incomplete. [7] is close to accurate. But, may have issues.
[7] is outside our jurisdiction. Our suggestion: there should be one set of
rules and all three must point to it. Where should that conversion rule
reside?

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

1.3.2 Lack of accuracy

When the type is not xs:QName or xs:NOTATION, why doesn't this accessor
always return
- the concatenation of the string-values of all the text nodes among its
<b>children</b> for elements, and
- the "string-value" property for attributes?
Are there cases where this approach doesn't work?

It seems [5] and [6] are trying to recover the original string in the
instance document, but isn't it already available in the text nodes and
string-value property?

Assume the above approach doesn't work, which means we have to cast atomic
values to string, then there are further comments.

- For "simple type or complex type with simple content" cases, don't we
need to consider derived types. That is, for example, instead of saying "If
the element type is xs:anyURI", we say "If the element type is or is
derived from xs:anyURI". Currently, only types derived from "xs:string" are
considered.
- The phrases "the string", "the URI", and "the value" are used in [5] and
[6], but it's not clear what they refer to. Some atomic value available
somewhere?
- In the case for xs:anyURI. "... returns the characters of the URI".
Editorial comment: shouldn't it be "... returns a string formed from the
characters ..."
- In the case of xs:QName
  - Shouldn't xs:NOTATION be considered in the same way as xs:QName?
  - "If the value has a namespace URI, then there must be at least one
prefix mapped to that URI in the in-scope namespaces. If there is no such
prefix, an error is raised ("no prefix defined for namespace")." Is it
still an error if the default namespace is mapped to that URI?
  - "If no error occurs, returns a string with the lexical form of a
xs:QName using the prefix chosen as described above, and the local name of
the value." But in the case where the value has no namespace URI, then
there is no prefix "chosen as described above".
- It seems that [6] doesn't consider types other than those listed. It
needs a new bullet with something like "In all other cases, ..."

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

1.4 [validity] = invalid on an ancestor

In section 6.2.4, for "type":

"* If the [validity] property exists and is ?valid? on this element and all
of its ancestors, type is assigned as described in 3.3.1 Mapping PSVI
Additions to Types
* Otherwise, xdt:untypedAny."

And in section 6.3.4, for "type":

"* If the [validity] property does not exist on this node or any of its
ancestors, Infoset processing applies.
  ...
* If the [validity] property exists and is "valid", type is assigned as
described in 3.3.1 Mapping PSVI Additions to Types
* Otherwise, xdt:untypedAtomic."

It seems that the rules for elements and attributes are different, in the
following case:
- [validity] exists on the current element/attribute and all its ancestors,
and
- [validity] is "invalid" on one of the ancestors, and
- [validity] is "valid" on the current element/attribute.

In this case, for elements, the type is "xdt:untypedAny"; but for
attributes, the type in PSVI is used. Is there a reason for such
difference?

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

1.8 Union of list of union

In section 7

"The value of a node whose type is a union type is represented by the
appropriate value for the appropriate member type of the union type. If the
member type is an atomic type, the value is represented as an atomic value
of that type. If the member type is a list type, the value is represented
as a sequence of atomic values whose type is the item type of the list
type. The union type information is lost and only the specific type of the
actual item is retained."

In the case where the member type is a list type, it's possible that the
item type of that list is another union type.

Proposed fix: change the whole list in section 7 with something like the
following:

"The value of a node is determined in the following way based on its type.
The rules apply recursively.

* If the type's [variety] is atomic, then the value is represented as an
atomic value of that type.
* If the type's [variety] is union, then the value is represented by the
appropriate value for the appropriate member type of that type. Note that
the member type's [variety] may be atomic or list. The union type
information is lost and only the specific type of the actual item is
retained.
* If the type's [variety] is list, then the value is represented by a
sequence of appropriate values based on the item type of that type. Note
that the item type's [variety] may be atomic or union."
"If the member type is a list type, the value is represented as a sequence
of atomic values whose type is the item type of the list type."

Decided at BEA face-to-face: DM/FS/F&O editors should review revised Section 7.

1.9 Element-content whitespaces

In section 6.7.3, for "content"

"Applications may construct text nodes in the data model to represent
insignificant white space."

In section 6.7.4, for "content"

"Construction from a PSVI is identical to construction from the Infoset."

Because construction from PSVI is identical to Infoset, processors are
still allowed to not include certain whitespaces in the text nodes.
- But there is always a possibility that DTD and XML Schema don't agree on
whether certain whitespaces are ignorable.
- It's even possible that if certain whitespaces are ignored after DTD
processing, the instance becomes schema-invalid. (Schema operates on all
characters, not only those that are not ignorable whitespaces.)

As an example to the second comment, consider

instance.xml

<!DOCTYPE E [
<!ELEMENT E (C?)>
]>
<E>   </E>

schema.xsd

<schema xmlns="http://www.w3.org/2001/XMLSchema">
  <element name="E" type="string" fixed="   "/>
</schema>

In the above example, the internal DTD declares an element E with
element-only content with an optional C element as its child. And in the
instance, the optional C doesn't appear in the content of E, and E only has
3 space characters as its children. And we have a schema, which declares
element E to have the "xs:string" type with a fixed value of 3 spaces.
Clearly, the instance is valid with respect to the schema.

Now we construct a data model from the PSVI, if we ignore those
element-content whitespaces (as allowed by 6.7.3), then we'll get an
element node for E, without any children. Now the data model doesn't seem
to be valid with respect to the schema anymore, because of the fixed value
on E.

Proposed fix: when a data model is constructed from PSVI, then all
whitespaces have to be included.

The particular problem identified here does not occur because we use the
SchemaNormalizedValue if it exists. But this section has been rewritten to clarify
the points raised by Schema.

1.10 Atomic values

In section 7

"[Definition: An atomic value is a value in the value space of an atomic
type labeled with that atomic type.]"

What's the meaning of "labeled with"? It feels like DM atomic values are
composed values, each of which has 2 properties: the schema atomic value
and the schema type, and a DM atomic value is certainly different from a
schema atomic value.

"The value space of the atomic values is the union of the value spaces of
the atomic types. This value space clearly includes those atomic values
whose type is primitive, but it also includes those whose type is derived
by restriction, as derivation by restriction always limits the value
space."

Because members of "the value spaces of the atomic types" are schema
values, members of "the value space of the atomic values" are also schema
values. This would imply that DM atomic values (composed values) are not in
the value space of the atomic values (schema atomic values). This is
counter-intuitive.

Proposed fix: we think that the intention is for DM atomic values to be the
same as schema atomic values, and it's always possible to find out the type
that was used to validate/generate a certain DM atomic value. If this is
true, then the "labelled with" phrase in the definition is a bit
misleading. Maybe "labeled with that atomic type" should be removed from
the definition, and a following note/description makes it clear that
whenever an atomic value is stored in the DM, there is always a way to
discover its corresponding type that was used to validate/generate the
value.

Decided at BEA face-to-face: DM/FS/F&O editors should review revised Section 7.

1.11 Value space of xdt:untypedAtomic

Section 7.1.2 has a short description about xdt:untypedAtomic, but it
doesn't answer the following question:
- What is the value space of xdt:untypedAtomic?
- Does it overlap with the values spaces of schema primitive types?
- Does it contribute to "the value space of the atomic values" (from
section 7)?

Without them being answered, it's difficult to understand the meaning of
something like (from section 6.1.2, for "dm:typed-value")

"Returns dm:string-value of the node as an xdt:untypedAtomic value."

An immediate question is how to return an "xs:string" AS an
"xdt:untypedAtomic" when they don't have sub-type relation, and when
xdt:untypedAtomic doesn't have a value space.

Proposed fix: we understand that this type is magic, and it shouldn't be
considered as an ordinary type (only used as an indicator). So to avoid the
confusion, the spec needs to make it clear that it's magic, and its value
space is not known, but this type can be used to "label" atomic values.

Decided at BEA face-to-face: DM/FS/F&O editors should review revised Section 7.

2. Other technical issues
2.1 Accessing unparsed entities

In section 6.1

Document nodes have a [unparsed-entities] property, which is a sequence of
entities. They also have accessors "dm:unparsed-entity-system-id" and
"dm:unparsed-entity-public-id". So there are ways to query the
system/public id of a given entity. Wouldn't it be useful to have an
accessor that exposes all entities within a document node?

Propose to introduce:

dm:unparsed-entities($node as document()) as xs:string*

and optionally:

dm:unparsed-entity-system-ids($node as document()) as xs:string*
dm:unparsed-entity-public-ids($node as document()) as xs:string*

(If the above 2 are introduced, then the processor must guarantee the order
of the entities is the same for all 3 accessors.)

Decided at BEA face-to-face: status quo solves existing use cases.

Announced.

2.3 Ignored namespace information items

In section 6.2.3, for "namespaces"

"Implementations may ignore namespace information items for namespaces
which do not appear in the expanded QName of any element or attribute
information item."

- It's not clear what "any (element or attribute ...)" means? Any
element/attribute in the whole instance document? Any descendent
elements/attributes?
- It's also possible that the value of some element/attribute is of type
QName/NOTATION, and we need to retain the namespace information for the
namespace URI in such value.

Proposed fix:

Implementations may ignore namespace information items for namespaces which
- do not appear in the expanded QName of the current element information
item or any of its descendent element or attribute information items, and
- do not appear in the value of the current element information item or any
of its descendent element or attribute information items, if the type of
such value is xs:QName or xs:NOTATION.

2.4 Order of children in element nodes

In section 6.2.4, for "children"

"The order of these nodes is implementation defined."

So even if a PI appeared before another PI in the infoset, it's allowed for
them to appear in the reversed order in the data model? This is
counter-intuitive.

Decided at BEA face-to-face: clarified.

Untyped data is one of the significant challenges in the design of the
XML Query type system. Two important criteria for the representation
of untyped data are:

1. We need a way to identify data that is not schema processed

It should be easy for a processor to identify documents or regions for
which no schema processing is done, either because the instance was
not schema validated or for nodes found in a skip-validated region of
a schema. This allows a processor to know that no typed data occurs
within the region. One way to do this is to use xdt:untyped for
elements that have not been schema-processed, and xdt:untypedAtomic
for attributes that have not been schema processed, and to use the
types assigned by XML Schema, including xs:anyType and
xs:anySimpleType, when schema processing has been done.

2. Compatibility with the XML Schema type system.

If a document has been schema-validated, the types used in the
document should be compatible with those given to it by XML
Schema. This is listed explicitly as a goal in our charter.

  It is a goal of the XML Query work to be compatible with the work of
  the XML Schema Working group on XML Schema Part 2: Datatypes (XML
  Schema Part 2) and XML Schema Part 1: Structures (XML Schema Part
  1).  For example, it should be possible to base query predicates on
  the existing DTD or XML Schema Part 1 definition of the content of
  an XML document and on the new data types being defined as part of
  the XML Schema Part 2. In addition the XML Query work will take
  advantage of the formal description of the contents of XML Schema
  defined in XML Schema: Formal Description (XML Schema: Formal
  Description).

When schema processing is done, the Data Model should use the same
type names as XML Schema. We currently map all instances of xs:anyType
to xdt:untypedAny [1] and mapping all instances of xs:anySimpleType to
xdt:untypedAtomic, which means that someone who understands XML Schema
must also understand how our types differ from those in the XML Schema
specification. If XML Schema assigns the type xs:anyType, the Data
Model should use the same type. If XML Schema assigns the type
xs:anySimpleType, this type should be preserved in the Data Model.

This is important not only for the comprehension of those poor souls
who must understand both XML Schema and XQuery's type system, but also
because XQuery and XSLT are not the only systems that use type
information from XML Schema. Since we use different type names,
software based on the PSVI has different type names for untyped data
than software based on the Data Model. A Java or C++ program using a
PSVI API will have the same type names as the Data Model for almost
every other named data type, but not for these two - which means that
someone using XQuery embedded in a Java program, or an XQuery that
makes external calls to Java, must be aware of the two sets of type
names and how they relate to each other. Also, a browser based on the
PSVI representation reports different type names than a browser based
on the Data Model, and debugging tools based on the two different
representations report different type names. This is especially
important since many of us see the Data Model as an important
simplification of the PSVI that may become the basis for many
specifications. It must not be at odds with XML Schema. Our charter
asks us to design a language, not to change the type hierarchy used by
XML Schema. If our language can't match a type in the type hierarchy
or express the type for the purposes of static inference, the solution
is to change the language, not the data model. Our status quo goes
against the charter in a way that hurts interoperability among
specifications and tools.

Jonathan

[1] This is called xdt:untyped in internal drafts that have not yet
been released.

Decided at joint telcon 185: overtaken by events.

I'd like to float a slightly radical idea in order to reduce our
problems handling QNames: we should treat an expanded QName as a triple
consisting of a prefix, uri, and local name.

The typed value of a QName-valued node would retain the original prefix
in rather the same way as a date/time value retains the timezone:
something that does not contribute to equality testing but is available
for use when converting back to a string. In retaining information
beyond what XML Schema considers to be the value space, we thus have a
precedent.

All operations on QNames work unchanged, they ignore the prefix. Except
for casting to string, which returns the prefix:local-name
representation.

This reinstates the ability to cast a QName to a string. The result may
not be very meaningful, because there is no way of knowing what the
prefix refers to; but it means that every atomic value can be cast to a
string without a failure and without any dependency on the context,
which makes life a lot easier. It means, for example, that writing a
QName-valued attribute such as xsi:type="{$qname}" will work, provided
that the user takes care to ensure the prefix is declared in the result
tree, whereas at present it always fails.

This doesn't solve the problem of converting a lexical QName to an
expanded QName, which can still only be done by providing a namespace
context. Therefore, I think we should continue to say that casting from
string to QName is not supported.

Making expanded-QName into a triple would suggest some changes to F+O:

(a) the expanded-QName() function should require a prefix to be supplied
(b) the node-name() function should establish a prefix (in the same way
as name()) alongside the local name and URI.

The fact that a prefix is present in the value doesn't mean that it has
to be used by all operations. For example, it doesn't constrain the
serializer to use this particular prefix.

Everything said here applies to xs:NOTATION as well as xs:QName, of
course.

Michael Kay

Data Model Section 3.2 (Construction from an Infoset): First bullet states 
that general and external parsed entities must be fully expanded, and the 
Infoset must not contain any unexpanded entity reference info items. This 
leaves open the question about unparsed entities. Can an Infoset contain 
unexpanded references to unparsed entities? If so, how are they 
represented in the data model? If not, the what is the use of the unparsed 
entity accessors of the document node?

Decided at BEA face-to-face: closed with no action required.

Data Model Section 3.3.3 (Storing xs:dateTime, xs:date, and xs:time 
values): This section says that ". . . Implementations must keep track of 
both of these values . . .", meaning the date or time converted to UTC and 
a separate timezone expressed as a dayTimeDuration. But the definitions of 
element and attribute nodes do not provide any way to do this. The data 
model lists all the properties of each kind of node. The properties of an 
element node are base-uri, node-name, parent, type, children, attributes, 
namespaces, and nilled. None of these properties provide a way to store a 
separate timezone if the element contains an xs:time. If the data model 
requires some piece of information to be stored for an element or 
attribute node, then it must provide a property for this purpose. This is 
an example of the kind of problem that will be exposed by carefully 
specifying the types of the various node properties. 

Decided at BEA face-to-face: clarified by most recent draft

In the Data Model document, each kind of node has a list of named 
properties, but the document does not in general specify the information 
that is contained in these properties. In some cases, the properties are 
directly associated with accessor functions from which their types can be 
deduced (for example, dm:nilled() returns a boolean, so presumably the 
nilled property contains a boolean). But in other cases it is not so 
clear. Some essential information, such as the "tuple" representation of 
dates and times, does not seem to be present in the node properties. The 
content of the various properties should be clearly explained (and 
enhanced, where necessary to support the accessor functions). The types of 
the properties should be declared where appropriate (some of them may be 
implementation-dependent).

Decided at joint telcon 185: Don to review and report if this comment has
been overtaken by events.

Data Model Section 6.1 (Document Nodes): XML documents have "version" and 
"standalone" declarations. Do these declarations affect the data model in 
any way? Do these declarations have any interaction with the "version" 
parameter of serialization? Some combinations do not seem to make any 
sense. For example, can an input document in XML Version 1.1 be serialized 
using XML Version 1.0? Does the data model need to record the XML version 
from which it was derived?

Decided at BEA face-to-face: additional prose added to spec.

Data Model Section 6.2.2 (Element Nodes--Accessors): The dm:typed-value 
accessor, second bullet, says that the typed value is derived from the 
string value and its type in a way that is consistent with schema 
validation. But it also says that, for date/time types, the typed value is 
"the atomic value derived from its tuple representation ...". These 
statements contradict each other. The string value does not contain any 
tuple representation. What property of an element node contains this 
"tuple representation"? Is the typed value derived from the string value, 
or not?

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model Section 6.2.4 (Element Nodes--Construction from a PSVI) and 
Section 6.3.4 (Attribute Nodes--Construction from a PSVI): Each of these 
sections has a rule about mapping the "type" property, but the rules are 
not the same. The element rule depends on whether the [validity] property 
exists and is "valid" on this element and all its ancestors. The attribute 
rule depends on whether the [validity] property fails to exist on this 
node or any of its ancestors, regardless of its value. What is the reason 
for this difference? It looks like a bug. It would be helpful if the rules 
were stated using the same language.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model Section 6.1.1 (Document Nodes--Overview), last paragraph talks 
about "Implementations that support DTD processing and access to the 
unparsed entity accessors". This seems to imply two optional features. Can 
an implementation choose whether or not to support or not support "DTD 
processing" and "unparsed entity accessors"? Should these items be added 
to our list of optional features?

Decided at BEA face-to-face: optional features to be listed in conformance section.

Data Model Section 6.3.2 (Attribute Nodes--Accessors): The dm:typed-value 
accessor claims to return the "atomic value that is determined from its 
tuple representation." But (as in the case of element nodes), the 
properties of an attribute node do not include any such "tuple 
representation". The typed-value accessor should be defined in terms of 
the properties of the node, and these properties should be extended if 
necessary to support the accessor.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model Section 6.4.1 (Namespace Nodes--Overview): This section states 
that the data model permits namespace nodes without parents (parent 
property may be empty). This should be changed. There is no longer a 
namespace node constructor in XQuery. There is no way to create a 
namespace node independently of an element node, and no reason why the 
data model should permit this. 

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model Section 6.4.2 (Namespace Nodes--Accessors): The dm:node-name 
accessor depends on whether the implementation "preserves information 
about prefixes declared." Is this an optional feature? Should it be on our 
list of optional features? If prefixes are not "preserved", then what 
purpose is served by namespace nodes?

Data Model Section 6.2.2 (Element Nodes--Accessors): The dm:string-value 
accessor does not seem to be defined in terms of the properties of an 
element node. This problem has many manifestations. For example, 

(a) "If the element type is xs:string, or a type derived from xs:string, 
returns that string."  Eh?  Returns what string? Does it mean that the 
value returned is the content property of the child text node? 

(b) "If the element type is xs:anyURI, returns the characters of the URI." 
 What URI? Again, are we talking about the content of the child text node?

(c) "If the element type is xs:QName": this bullet has many problems. It 
discusses a "value" but does not specify where the value is found. It 
discusses the case when "in-scope namespaces map the default namespace to 
any namespace URI". Does this mean that the default namespace is a 
specific (rather than "any") URI? It refers to an error, "default 
namespace is defined". But this error needs a better 
description--certainly it is not an error simply to define a default 
namespace. Also, the list of subcases seems to be incomplete. The first 
bullet deals with the case when the "value" has no namespace URI and the 
default namespace satisfies some (poorly specified) condition; but what 
about the case when the the "value" has no namespace URI and the default 
namespace does not satisfy this condition?

(d) "If the element type is xs:dateTime, . . .": This paragraph requires 
the "original lexical representation" to be returned by the string-value 
accessor. But I believe there is no such requirement--isn't it possible 
that the original lexical representation might have been normalized into 
some different but equivalent representation? In general we do not attempt 
to preserve "original" lexical representations. Also, presumably this 
section applies to subtypes of the date/time types as well as the 
date/time types themselves. Also, this section describes how to compute a 
string-value from a "normalized value" and an "explicit timezone", but 
these things are not among the listed properties of an element node.

(e) "In all other cases, returns the concatenation of the string-values of 
all its text node descendants in document order." Finally, something that 
is actually found in the data model! Unfortunately, this sub-bullet is 
under the higher-level bullet where the "element has a simple type or a 
complex type with simple content." But in these cases, the element node 
has only a single text-node child, so why are we talking about 
"descendants"?

(f) If the element has a simple type or a complex type with simple 
content, why doesn't the string-value accessor simply return exactly the 
content of the child text node? If the child text node doesn't contain the 
string-value in these cases, then what does it contain?

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model Section 6.3.2 (Attribute Nodes--Accessors): Why doesn't the 
dm:string-value accessor simply return the string-value of the attribute, 
since it is a node property? If the string-value accessor returns 
something other than the string-value property, then why does the node 
have a string-value property? Why are we talking about things like 
"original lexical representation", "normalized value", "explicit 
timezone", and "tuple representation" which are not stored in any property 
of an attribute node?

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data Model Section 6.3.4 (Attribute Nodes--Construction from a PSVI): 
Earlier sections have stated that for date/time values, an explicit 
timezone must be captured. This mapping section does not describe any way 
in which the explicit timezone of a date/time value is extracted from the 
PSVI.

Decided at BEA face-to-face

Data Model Sections 7.11 (xdt:untypedAny) and 7.1.2 (xdt:untypedAtomic): 
The first sentence of each section begins with "The abstract atomic type 
...". This is not correct. Both of these types are concrete types, not 
abstract types.

Accepted editorial suggestions.

Data Model Section 6.4.1 (Namespace Nodes--Overview): The last sentence of 
the last paragraph states that "Elements never share namespace nodes." It 
should be clearly stated that this rule applies only to implementations 
that expose the namespace axis. For implementations that do not expose 
this (deprecated) axis, sharing namespace nodes is a very reasonable 
strategy. For example, in Appendix D, just before the box containing 
Document Node D1, we read, "We're assuming an implementation that does not 
expose the namespace axis. Therefore we can share namespace nodes across 
multiple elements." 

Decided at BEA face-to-face: added a note to this effect.

The DM speaks of in-scope namespaces, this needs to be clarified to refer to
the namespaces() accessor. In the case of attributes, we must make sure that
namespaces() of the parent element, if there is one, is used.
    

Decided at BEA face-to-face: clarified in next draft.

There are a few accessors in the Data Model that raise errors.
What does this actually mean?

Decided at joint telcon 185: close without change.

Section 7.1.1 xdt:untypedAny	
Technical	

Definition needs to adjust to deal with partially validated content. See
http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Jan/0033.html
(member-only).

The sections on types and atomic values have been extensively redrafted
to address this and several other comments.

Section 7 Atomic Values	
Technical	

"The union type information is lost and only the specific type of the
actual item is retained." & "The value of a node whose type is a list
type whose item type is an atomic type is represented by a sequence of
atomic values whose type is the item type." &"The value of a node whose
type is a list type whose item type is a union type is represented by a
sequence of atomic values, each of whose type is one of the member types
of the union type. The union type information is lost and only the
specific types of each individual item is retained.": See comment
MS-DM-LC2-039

MS-DM-LC2-039 is closed. This issue is overtaken by that one?

Section 6.7.3 Construction from an Infoset	
Editorial	

Is "Applications may ignore character information items for which
[element content white space] exists and is "true"."
implementation-defined or -dependent semantics?

The section has been redrafted to make the decisions recorded at the f2f
clear.

Section 6.7.1 Overview	
Technical	

Why can't we have the constraints about no text nodes allowed to have
zero-length string only implied by the parent (doc or element) node, but
allow an explicit text node constructor to generate a text node with
zero-length string content. This would simplify the semantics and
optimization of text node constructors.

Decided at joint telcon 183: allow parentless zero-length text nodes.

Section 6.5.2/6.6.2 Accessors	
Technical	

Type of typed values of comments and PIs should be xdt:untypedAtomic and
not xs:string due to XPath 1.0 backwards-compatibility. Also in an
untyped document, then ($a/node())[1] + 1 will work with
xdt:untypedAtomic but not with xs:string in a static typing
implementation.

This comment also affects the XQuery and Formal Semantics documents.

    

Decided at BEA face-to-face: typed-value is xs:string

Section 6.2.2 Accessors	
Technical	

We should make the rules for dm:typed-value simpler and make all
non-simple typed content the same as dm:string-value(). Also applies to
fn:data() and atomization. 

The reason is that static implementations will have the problem that
they have to otherwise raise a type error on even mixed content typed
elements, since an instance may be of a derived complex-content type
that is not mixed.

Also note that this would change the typed value of an element with
empty content type from () to "".

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Section 3.3.3 Storing xs:dateTime, xs:date, and xs:time Values in the
Data Model
Technical

We believe that preserving the timezone information is overkill and
should not be mandated to be preserved. Preserving presence and absence
is enough, the values with a timezone should be normalized to UTC+0 and
timezone generation should be left to formatting functions.

    

Decided at BEA face-to-face: rejected.

Section 3.3.1 Mapping PSVI Additions to Types
Technical

The rules about inferring type annotations seems to break named typing
in the context of union types.

The instance type of the element needs to be the name of the union type
and not the name of the member type that matches the instance's type.
Otherwise

$n instance of element(*, uniontype)

Will fail.

Decided at joint telcon 183: resolved to make the type of nodes always the union
type and the type of the atomic values the member type. This was approved
at meeting 185.

Section 6.1.1 Document Nodes Overview	
Technical	

We do not believe that the document URI should be listed as a property
in the specification. While some implementations may want to provide
this information (along with other information such as owner, ACLs,
date, size), not every implementation will be able to provide this
information and others may have different document URIs for the same
document based on the access path chosen. Since the specification should
define common properties, this property should be removed (the same
argument will be raised for the corresponding functions to access the
property in F&O, so we will not be accepting an argument that this is
needed for the access-functions).

    

Decided at BEA face-to-face: added property.

Section 3.3.1 Mapping PSVI Additions to Types	
Technical	

The validity information mapping is incorrect and we should drop support
for validity property "invalid" in the data model specification since we
do not see a need for defining an interoperable data model for the
invalid case.

This is related to comment MS-DM-LC2-035 and the issue discussed in
http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Jan/0033.html
(member-only).

    

Decided at BEA face-to-face: rejected.

The data model introduces the name xdt:anyAtomicType to refer to the
abstract superclass of all atomic types.

It would also be useful to have names for the other abstract types implicit
in the data model, specifically:

xdt:anyListType
xdt:anyUnionType
xdt:anyComplexType

These would then be available for use in the SequenceType production. For
example, one could define a template rule

<xsl:template match="attribute(*, xdt:anyListType)">

to match all list-valued attributes.

Michael Kay

    

Decided at BEA face-to-face: rejected for V.current.

General	
Technical/Editorial	

We need consistency rules for consistency of structured types. Something
along the lines that if an instance has been validated as of type foobar
with structures a and b, that the data model instance has the right
children and types...

The sections on types and atomic values have been extensively redrafted
to address this and several other comments.

Section 3.3	Construction from a PSVI	
Technical	

We do not see a reason to support "incompletely validated documents".
Actually this makes it impossible to support statically typed
implementations on top of such data models that guarantee type-safety.
It also is unclear if such an element is untyped or partially typed. The
later is a concept that currently does not exists in our type system.
Please remove this remark.

Decided at BEA face-to-face: rejected

Section 2.5	Types	
Technical	

The actual anonymous types form should be implementation-dependent.
There is not official way of exposing it to the user anyway at the
moment.

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Section 2.4	Document Order
Major Editorial/Minor Technical

The general constraints in section 2.4 should be reorganized. A rewrite
proposal below.

For example, bullet 2 does not belong here. It is a description of a
mapping of the XML to the DM and should not be used to describe the DM.
Use Depth-first traveral of the ordered nodes of the tree instead.
Namespace nodes/attribute nodes: remove stable since it says so earlier.
Also define stable to mean on a per query/transformation basis, not for
a persisted data model instance. Add 4.1 All children follow attribute
nodes. Clarify defintion of term "Children": Excludes namespace and
attribute nodes. Remove bullet 5 since it is covered by depth-first
traversal. Add normatively in 2.3 or 2.4 that every node can only appear
once in a tree, but could appear more than once in a sequence. Then it
can be removed in all the subsequent subsections (6.1, 6.2 etc.). Move
general tree constraint "If a node n is a child of a node p, then the
parent of n is p" into 2.4 (maybe rename 2.4 into document structure)
and remove it from later sections.

Here is a proposal:

Somewhere prior to 2.4 (possibly 2.3? or some subsection called
"document structure"), the following concepts must be stated:
 
Each node appears exactly once in exactly one tree.  The same node may
appear multiple times within a sequence.
The children of a node do not include namespace or attribute nodes.  A
node P is the parent of a node N if and only if N is in the children of
P.
 
When describing how XML representations are mapped into the data model,
include this paragraph:
 
The relative order of siblings is determined by their order in the XML
representation of the tree.  A node N1 occurs before a node N2 in
document order if and only if the start of N1 occurs before the start of
N2 in the XML representation.
 
 
Then change 2.4 to:
 
2.4 Document Order
A document order is defined among all the nodes used during a query or
transformation.  Document order is a total ordering across all nodes
used in a query, although the relative order of some nodes is
implementation-dependent.  Document order is stable, which means that
the relative order of two nodes does not change during the processing of
a given query or transformation, even if this order is
implementation-dependent.  The relative order may change from one query
to the next.
 
Within a tree, document order is the order returned by an in-order,
depth-first traversal of the data model, and satisfies the following
constraints:
 
1. The root node is the first node
2. Namespace nodes immediately follow the element node with which they
are associated.  Their relative order is implementation-dependent.
3. Attribute nodes immediately follow the namespace nodes of the element
with which they are associated. The relative order of attribute nodes is
implementation-dependent.
4. Children follow their parent node.  All children of an element
immediately follow its attributes.
 
Across trees, document order is stable but implementation-dependent.
From the above description, it follows that if any node in a tree T1 is
before any node in a tree T2, then every node in T1 is before every node
in T2.

The doc() function in F&O (and indirectly the document() function in
XSLT) specify that if the representation of a resource returned from
some URI is an XML file then the input tree should be constructed as
specified in DM, modulo some specific implementation dependent features
such as which uri schemes are supported.

In DM it says:

  6.7.3 Construction from an Infoset

  Applications may construct text nodes in the data model to represent
  insignificant white space. This decision is considered outside the scope
  of the data model, consequently the data model makes no attempt to
  control or identify if any or all insignificant white space is ignored 


This appears to be contradictory. Unless the document has been validated
(and so some element is known not to have mixed content) all space is
significant.  But this is describing building a datamodel from the
infoset not from the PSVI, so it hasn't been schema validated at least,
and I'm not sure if the DM really takes note of DTD validation as
currently written.


The only occurrence of the word "significant" in the infoset document is

    White space within start-tags (other than significant white space in
    attribute values) and end-tags.

which clearly is irrelevant here.


In current XSLT1 applications more or less the only significant
incompatibility between implementations (baring bugs) is msxsl's
tendency to drop spaces. (If called from an API a more conforming
behaviour can be specified, but notably _not_ if called via the
xml-stylesheet PI) This means that the (in most ways excellent) msxsl
implementation will render an xml fragment such as
<p><b>Bold</b> <span>words</span> <i>italic</i></p>
as
Boldwordsitalic
if given an "identity transform" to html as it will decide that
inter-word spaces are insignificant. Arguably this is conformant (if
confusing) behaviour as XSLT/XPath 1 said essentially nothing about how the
tree should be built. I believe that in version 2 of the language it is
clear that the wording should be clarified so that this unfortunate loss
of interoperabiliy (and usability) is clearly not allowed without some
specific user-option that requests it.


I fear that the wording in 6.7.3 was intended to authorise the dropping
of the interword spaces in my <p> example. It fails to do that as 
it refers to a term "insignificant white space" that is apparently
undefined, however I believe that the comment should be deleted rather
than fixed. It is an unnecessary optional clause to stop
interoperability, systems storing documents in efficient database
storage forms can construct the data model instance in any way they
like, there is no need to allow systems that are parsing explict XML
documents to have the same flexibility.

there is some discussion of this on xml-dev

http://lists.xml.org/archives/xml-dev/200307/msg00148.html

(and any number of posts on xsl-list where users have fallen into this
trap and asking where their spaces went, or why some node count that
went 1,2,3 on msxsl goes 2,4,6 on every other processor)

White space is now significant in all cases except element-only content
where it is not significant. The draft has been clarified to reflect this.

1.1. The term type

    DM appears to use the term type for several related but different
    concepts; we believe it would be desirable if you were to clarify the
    meaning of the term, or at least if you called the reader's attention
    to its overloading.
    The Data Model specification appeals to the Formal Semantics
    specification, which says types are XML Schema types. However, XML
    Schema tries to avoid the term "type", instead using "type
    definition".
    Among the uses of "type" we have noticed are:
     1. T1. a name (for example, as used by the dm:type accessor).
     2. T2. a set of values (this sense is used by XML Schema's internal
        work on a formalization, which includes a "Type Lattice").
     3. T3. an XML Schema Type Definition component (simple or complex).
        Defines a set of values and certain properties, such as [name],
        [baseType], etc.
     4. T4. an OO class. Defines a set of values, inheritance info, and
        operators.

    Specifically, we suggest that the dm:type accessor be renamed to
    dm:type-name and that "type" be explicitly defined. If "type" is just
    a synonym for "type definition", say so in the definition ot "type".

Decided at joint telcon 183: occurrences of the word ‘type’ have been qualified.

1.3. Items and singleton sequences

    Section 6 Sequences reads in part:

      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.

    One consequence of this characteristic is that the types xs:integer
    and a list of xs:integer with length constrained to 1 have exactly the
    same value space in the Data Model. That is, each value in the value
    space is a sequence of a single xs:integer. This is different from the
    XML Schema value spaces for the two types. Might this cause a problem
    for functions or other uses of the Data Model?
    We believe further discussion is needed here.

The WG feels comfortable with the current model. Closed with no action.

1.4. The implications of [validity] != valid

    Section 3.6 para 2 reads in part: "The only information that can be
    inferred from an invalid or not known validity value is that the
    information item is well-formed."
    This is not true in the general case: the values of the properties
    [validity] and [validation attempted] interact, so that some
    inferences beyond well-formedness can be made. (If [validity] is
    'notKnown', for example, we can infer without examining the PSVI that
    [validation attempted] is not 'full'. If for some node N [validity] is
    'invalid', we can infer that declarations are available for at least
    some element or attribute information items in the subtree rooted in
    N.) The data model doesn't have to be interested in those inferences,
    but it is simply incorrect to say that they don't exist.
    On the whole, we believe that that the data model misses an
    opportunity by failing to exploit the information contained in the
    [validity] and [validation attempted] properties more fully.

The offending text "The only information ... is well-formed" has been
redrafted in the following way in response to your comment. Please let
us know if this is satisfactory.

  In the data model, precise schema type information is exposed for
  Element and Attribute Nodes that are
  valid. Nodes that are not
  valid are treated as if they were simply
  well-formed XML and only very general schema type information is
  associated with them.

1.5. Anonymous local types

    Section 3.6 has an extended list of cases describing how the namespace
    and local name of a type are found. This list reads in part:

      * If the [validity] property exists and is `valid':
           + ...
           + If the [type definition] property exists and its {name}
             property is present:
                o the {target namespace} and {name} properties of the
                  [type definition] property.
           + ...
           + If [type definition anonymous] exists:
                o If it is false: the [type definition namespace] and the
                  [type definition name]
                o Otherwise, the namespace and local name of the
                  appropriate anonymous type name.

    The above structure does not handle the case of an anonymous type when
    the schema processor provides the [type definition] property instead
    of the [type definition name] property and its fellows.
    We think the [type definition] rule can readily be rephrased so that
    the result is parallel to the case when the upstream schema processor
    provides [type defintion name] instead of [type definition]:

      * If the [validity] property exists and is `valid':
           + ...
           + If the [type definition] property exists[DEL: and its {name}
             property is present :DEL] :
                o [INS: If the [type definition]'s {name} property exists:
                  :INS] the {target namespace} and {name} properties of
                  the [type definition] property.
                o [INS: Otherwise, the namespace and local name of the
                  appropriate anonymous type name. :INS]
           + ...

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

3.2. Comments not reviewed by the Working Group

    When the XML Schema Working Group reviewed the draft comments provided
    by our task force, we focused on substantive comments; the following
    editorial comments were not reviewed owing to lack of time. They are
    transmitted on behalf of the Working Group, but they do not
    necessarily carry the consensus of the Working Group.
     1. Section 3.3 para -1: "inconsistent data models are forbidden".
        There has not thus far been any definition of consistency for data
        models; if it's provided elsewhere, a forward reference might be
        in order. If it's not provided elsewhere, it needs to be.
     2. abstract. For "the data model of at least XPath 2.0 ... and any
        other specifications that reference it" perhaps read "the data
        model of XPath 2.0 ... and of any other specifications that
        reference it".
     3. Section 1 Introduction para 2: "... it defines precisely the
        information contained in the input to an XSLT or XQuery
        processor."
        Surely it specifies a minimum, by defining the information which
        must be contained, rather than specifying both a minimum and a
        maximum by forbidding any input to contain any other information.
        If one has concealed a coded message in a document by varying the
        amount of white space before the '>' characters which close the
        tags in an XML document, that coded message is certainly (a)
        information, and (b) present in the input to the processor and (c)
        not defined by this Data Model.
        It may make sense to say that this document defines precisely
        which information present in the input it is that is relevant to
        XSLT or XQuery processors (although formulating this without
        falling into traps is also fraught with difficulty), but it seems
        simply wrong to deny that information other than what is defined
        here is present in the input.
     4. Section 2 Notation. Since this is to be a free-standing document,
        a short description of what the sample signature means would be
        useful. As it is, the combination of (a) the sample, clearly
        intended to help the reader understand the notation, with (b) the
        absence of any explication, manages to do a rather effective job
        of sapping the reader's will to continue reading.
     5. Section 3.3 para -1. "Validation is described conceptually as a
        process of ..." -- either insert a pointer to the section or
        document which provides this description or (if this is the
        description) read "Validation is a process of ..."
     6. Section 3.4 para 2. For "For named types, which includes ..." read
        "For named types, which include ..." (subject-verb agreement)
     7. section 3.4 para 6. "The data model defines ... It returns ... if
        it ..." The noun phrase "data model" is almost certainly not
        intended as the antecedent of either of the two occurrences of it,
        but syntactically it has a better claim than any other noun phrase
        around. For the first, perhaps read "The accessor"; for the
        second, perhaps "the node" or "the argument".
     8. section 3.4 para -1. For "The semantics of such operations, e.g.
        checking if a particular instance of an element node has a given
        type is defined in [Formal semantics]" read "... if a particular
        instance ... has a given type, is defined in ...".

We believe these comments are all addressed in the 23 July draft.

2.4. Elements labeled xs:anyType in the PSVI

    Section 4.3.2 says in part:

      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 contradict section 4.1.6:

      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.

----

2.5.2. Prefix property

    Section 4.3.4 says:

      An implementation must construct the value of the [prefix] property
      as if the following algorithm was applied: if the element has at
      least one namespace node whose namespace URI is the same as the
      namespace name of the xs:QName returned by the dm: node-name
      accessor ...

    Please be clear about the meaning of "namespace URI" or the namespace
    node. Is it the [uri] property of the namespace node or the namespace
    uri part of the node-name property of the namespace node?

----

2.5.3. Sequences in sequences

    Section 2 reads in part:

      In a sequence, V may be a Node or AtomicValue, or the union
      (choice) of several categories of Items.

    It's not immediately clear to all readers what this means. It appears
    a first glance to say that if V*, V?, or V+ appear in (the description
    of) a sequence, then V may be or denote a Node or an AtomicValue or a
    union. But if sequences cannot appear in sequences, and V* and V? and
    V+ all denote sequences (as specified in the list immediately above),
    then if V*, V?, or V+ appear in (the description of) a sequence S,
    then sequence S would appear to violate the rule that sequences cannot
    contain other sequences. (Unless "In a sequence" means `When appearing
    as the description of a sequence'.)
----

2.5.4. Synthetic data models

    Section 3.3, para 2 reads:

      Although we describe construction of a data model in terms of
      infoset properties, an infoset is not an absolutely necessary
      precondition for building an instance of the Data Model. Purely
      synthetic data model instances are entirely appropriate as long as
      they obey all of the constraints described in this document.

    We agree that it is worthwhile to point out that synthetic instances
    of the Data Model are possible, and need not derive from some
    pre-existing XML document or information set. Some members of the XML
    Schema WG believe, however, that the formulation just quoted does not
    do full justice to the abstract nature of the infoset as a concept.
    Any process which can create an instance of the Data Model clearly has
    access to the set of information defined by the Infoset Rec and can
    thus be thought to have, or be, an infoset itself. To this line of
    thinking, the construction of a synthetic Data Model is itself a
    sufficient demonstration that the necessary information, and thus the
    necessary infoset, is available.
    Two possible fixes may be worth suggesting:

      Although we describe construction of a data model in terms of
      infoset properties, a [INS: pre-existing :INS] infoset is not an
      absolutely necessary precondition for building an instance of the
      Data Model. Purely synthetic data model instances are entirely
      appropriate as long as they obey all of the constraints described
      in this document.

    Or

      Although we describe construction of a data model in terms of XML
      infoset properties, a [INS: pre-existing XML document :INS] is not
      an absolutely necessary precondition for building an instance of
      the Data Model. Purely synthetic data model instances are entirely
      appropriate as long as they obey all of the constraints described
      in this document.

/ Asir Vedamuthu <asirv@webmethods.com> was heard to say:
| I have a quick question. I am wondering if these issues are recorded in a
| last call issues list. If so, may I request you to send me a link?

They are now recorded[1]. Apologies in advance for any formatting
glitches; like the rest of the XSL/XML Query editorial team, I'm still
getting used to the ExIT system.

Asir/Michael/Schema WG: please acknowledge that you accept resolution
of qt-2003Aug0002-14, the issues I believe have been overtaken by
events.

Paul: please add qt-2003Aug0002-03 (1.3. Items and singleton sequences) and
qt-2003Aug0002-04 (1.4. The implications of [validity] != valid) to the
discussion list for the f2f. (And accept my apologies for tardiness, please.)

                                        Be seeing you,
                                          norm

[1] http://www.w3.org/XML/Group/xsl-query-specs/last-call-comments/xpath-datamodel/issues.html

> | [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.

> My understanding is that if [member type definition] exists and has no
> {name} property then [member type definition anonymous] also exists.
> Is that not the case?

No.

Either:

you are a fully-featured schema validator, and you have the [type
definition] property and (if the type is a union) the [member type
definition property],

... or ...

you are a wimpy schema validator, and you have the [type definition
type], [type definition namespace], [type definition anonymous] and
[type definition name] properties, and (if the type is a union) the
[member type definition namespace], [member type definition anonymous]
and [member type definition name] properties.

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Hello,

     Following are comments on Data Model that we believe to be editorial 
in nature.

------------------------------------------------------------------

Global

Data model error messages should be numbered, as in other specifications

------------------------------------------------------------------

Section 2.2.1

The F&O namespace URI is out of date. It should be "
http://www.w3.org/2003/11/xpath-functions".

------------------------------------------------------------------

Section 2.5

The first paragraphs states that "an expanded-QName uniquely identifies 
such a type."  It is possible for different schemas to define different 
types that have the same expanded-QName, although at most one such type 
will be available in the data model.  That should be clarified.

------------------------------------------------------------------

Section 3

In the last paragraph, "documents nodes" should be "document nodes".

------------------------------------------------------------------

Section 3.2

The second sentence begins, "A data model can only be constructed from 
infosets that satisfy the following general constraints. . . ."

Given that an implementation can construct a data model in implementation 
defined ways, a processor could conceivably construct the data model from 
an Infoset that does not meet these constraints.  The words "can only be 
constructed" are too strong.

The last sentence in the section needs to be similarly qualified to 
indicate that the statement only applies if the data model is constructed 
from Infoset as described.

------------------------------------------------------------------

Section 3.3

The second sentece of the first paragraph states that "Constructing an 
instance of the data model from a PSVI must be consistent with the 
description provided in this section. . . ."

Given that an implementation can construct a data model in implementation 
defined ways, a processor could conceivably construct the data model from 
a PSVI in a manner that does not meet these constraints.  The word "must" 
is not appropriate.

------------------------------------------------------------------

Section 3.3.3

In the last example, "2003-01-16T16:30:00" should be
"2003-01-02T16:30:00".

------------------------------------------------------------------

Section 3.3.4

For clarity, in the first bullet, after "timezone component is not the 
empty sequence", add "(timezone was specified)".

------------------------------------------------------------------

Section 3.3.4

For clarity, in the second bullet, after "timezone component is the empty 
sequence", add "(timezone was not specified)".

------------------------------------------------------------------

Section 5

In the third sentence of the second paragraph, "interface" should be 
changed to "information".  The accessors do not provide a programming API.

------------------------------------------------------------------

Section 5.2

"namespace" is missing from the list of possible values that dm:node-kind 
can return.

------------------------------------------------------------------

Section 5.5

A proper definition of the term "string value" is required.  When the data 
model is created from Infoset or PSVI, as described in this document, the 
meaning is relatively straightforward, but in other cases its not so 
readily apparent.

------------------------------------------------------------------

Section 5.6

A proper definition of the term "typed value" is required.  When the data 
model is created from Infoset or PSVI, as described in this document, the 
meaning is relatively straightforward, but in other cases its not so 
readily apparent.

------------------------------------------------------------------

Section 6.2.4

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

------------------------------------------------------------------

Section 6.2.4

In the second bullet under "type", it would probably be worth pointing 
that this default value is consistent with construction from Infoset, as 
is done at the end of this section.  Similarly, other defaults for PSVI 
could be described in terms of the mapping from Infoset.

------------------------------------------------------------------

Section 6.2.4

In the first bullet under "children", "string value is the the" should be 
"string value is the".

------------------------------------------------------------------

Section 6.3.4

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

------------------------------------------------------------------

Section 6.3.4

In the description of the string-value property, it's probably worth 
noting explicitly that the original lexical representation of the 
attribute is not preserved.

------------------------------------------------------------------

Section 6.4.3

Under the dm:node-name accessor in 6.4.2, it's stated that an 
implementation might not preserve information about prefixes declared, but 
the description of how the prefix property is created from Infoset doesn't 
mention that possibility.  In most other cases, the description of the 
accessor is unconditional - simply returning the value of a property - and 
it is the underlying property that has associated conditions.  It would be 
better to use a consistent style.

------------------------------------------------------------------

Section 6.5.3

The title of this section should be "Construction from an Infoset" for 
consistency with earlier sections.

------------------------------------------------------------------

Section 6.5.3

This section indicates that processing instructions might be ignored by 
the process that constructs the data model.  This should be moved to 
6.5.1.  Similar information on how namespace nodes could be handled by an 
implementation that does not support the namespace axis is provided in the 
"Overview" section (6.4.1), rather than the "Construction from Infoset 
Section" (6.4.3).

------------------------------------------------------------------

Section 6.6.3

The title of this section should be "Construction from an Infoset" for 
consistency with earlier sections.

------------------------------------------------------------------

Section 6.6.3

This section indicates that comments might be ignored by the process that 
constructs the data model.  Similar information on how namespace nodes 
could be handled by an implementation that does not support the namespace 
axis is provided in the overview section.

------------------------------------------------------------------

Appendix A

The last bullet of the first list indicates that the [prefix] property of 
Namespace information items must be exposed.  However, section 6.4.2 
indicates that an implementation might not preserve information about 
prefixes declared.  That optionality should be raised here.

------------------------------------------------------------------

Appendix A

The lead-in for the second bulleted list should indicate that PSVI 
properties mentioned are only required if the data model is constructed 
from PSVI.  (It could still be constructed from Infoset, even if only a 
subset of PSVI is available.)

------------------------------------------------------------------

Appendix B

The reference to Infoset should be updated to point to Infoset, second 
edition.

------------------------------------------------------------------

Appendix B

The links and publications dates are incorrect for F&O and for 
Serialization.

------------------------------------------------------------------

Appendix C

The definition of "fragment" as it appears in the glossary doesn't make 
too much sense.  Perhaps it should read "A tree whose root node is not a 
document node is referred to as a fragment."

------------------------------------------------------------------

Appendix D

In the example box for Attribute A1, the value of the dm:node-name
accessor is described as

  xs:QName("http://www.w3.org/2001/XMLSchema-instance",
           "xsi:schemaLocation")

"xsi:schemaLocation" should be "schemaLocation".


Similary, for Attribute A2, "xml:lang" should be "lang", for Attribute A6, 
"xlink:href" should be "href", for Element E5, "html:p" should be "p", for 
Attribute node A11, "xsi:nil" should be "nil".

------------------------------------------------------------------

Appendix D

In the example box for Comment C1, the value of the dm:typed-value 
accessor should be equal to the value of the dm:string-value accessor as 
an xs:string.

------------------------------------------------------------------

Appendix D

The orientation and size of the diagram at the end of this appendix make 
it difficult to read.  It might help to have to orient normally, with text 
in boxes running vertically, rather than horizontally.  Or, simply 
acknowledge that the compressed diagram isn't usable, and point to a 
larger image that is oriented normally, which people might not be able to 
print.

------------------------------------------------------------------

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Accepted editorial suggestions.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Appendix D

In the last paragraph before the tree diagram, two instances of "in-order" 
should be "pre-order".

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]

Accepted editorial suggestions.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Sections 7.1.1 and 7.1.2

The first paragraphs of 7.1.1 and 7.1.2 describe xdt:untypedAny and 
xdt:untypedAtomic as abstract types.  Section 2.4.1 of XPath describes 
these as concrete types.  The description in XPath is correct.  The 
sentences in these sections need to be corrected.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM, not just personally.]

Accepted editorial suggestions.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 6.4.2

The description of the dm:typed-value accessor should provide some 
rationale as to why the typed value of a namespace node is 
xdt:untypedAtomic, as opposed to xs:string or xs:anyURI.  This also 
applies to other dm:typed-value accessor definitions.  Otherwise, the 
types might seem as if they were selected randomly.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM, not just personally.]

Accepted editorial suggestions.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 6.1.2

The last paragraph indicates that all document nodes in a collection have 
the same base URI.  We don't believe that is really a requirement of 
fn:collection.

If there is no such requirement, "even though each has the same 
dm:base-uri" should be changed to "even if each has the same dm:base-uri". 
 If such a requirement does exist, it should be described in the 
definition of fn:collection in F&O.

Accepted editorial suggestions.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 3.3.3

This indicates the timezone in a date, time or dateTime value is 
represented as a duration.  It might not be obvious to the reader why that 
is, so it would probably be worthwhile explaining that it's treated as an 
offset from UTC.

Accepted comment; added note.

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]
[Speaking on behalf of reviewers from IBM, not just personally.]

Section 2.5

In speaking of types, the first paragraph mentions built-in types defined 
by XML Schema Part 2 and user-defined types.  It also needs to mention the 
types in the xdt namespace, and point to their definitions in Section 7.1.

Thanks,

Henry

Accepted editorial suggestions.

SECTION no specific location

This specification uses the phrase "data model" for more than one 
meaning.  The meanings are:

1. In section 1, "Introduction", second para: "The XQuery 1.0 
and XPath 2.0 Data Model (henceforth "data model") serves two 
purposes. First, it defines precisely the information contained 
in the input to an XSLT or XQuery processor. Second, it defines 
all permissible values of expressions in the XSLT, XQuery, and 
XPath languages."  Thus the data model is not a value, it is an
abstraction describing possible values.  

2. section 2.1 "Terminology", fourth para, last sentence:
"This might apply, for example, to limits on the size of data 
models that can be constructed."  What I think you mean here is the 
complete set of values found in the execution environment of some
execution of XQuery, XPath or XSLT.  Or section 2.4 "Document 
order", first para, last sentence: "document order is the order 
returned by an in-order, depth-first traversal of the data model."
In this sentence, "data model" means the complete set of trees 
in the execution environment of some particular expression
evaluation.

3. Section 3.1 "Direct construction", first sentence, it says "this
document describes the construction of a data model."  What you
mean by "data model" in this sentence is a single value 
(possibly a complex value, such as a tree or a sequence).

Please adopt three terms for these three notions, and 
then do a search for "data model" to insure that you are
using the appropriate term in every instance.

Decided at joint telcon 185: define the term “instance of the data model”
and use it consistently to distinguish between the cases.

SECTION 2.3: node identity

It says "The data model is a node-labeled, directed graph, in which 
each node has a unique identity."  What about atomic values?
I don't know whether they have identity or not, but I do know 
that they are not "nodes".  In addition, if "the data model...is a 
graph", why not provide us with a diagram of it?

Of course, the reason you cannot present the specific graph is
because there is no specific graph.
This highlights that the data model is an abstraction,
a rich framework that permits many kinds of values, among 
them being trees.  

I think what you mean is "An instance of the data model may contain
node-labeled, directed graphs, in which each node has a unique 
identity."  I am using "instance of the data model" as my 
preferred term for "the complete assemblage of all values 
available during the evaluation of an XQuery or XPath expression".

Accepted editorial suggestions.

SECTION 1: Introduction

In paragraph 5, the spec stated,
"Every value in the data model is a sequence of zero or more items."
It went on to discuss "node" and "atomic value" in paragraph 6 and 7.

Paragraph 6: "Every node is one of the seven kinds defined in 6 Nodes..."

Paragraph 7: "An atomic value encapsulates an XML Schema atomic type
and a corresponding value of that type..."

A sentence should be appended in paragraph 5 to clarify what is an
item, say ", and an item may be a node or an atomic value". This would
bridge the current conceptual gap between sequence and node/atomic
value.

Accepted editorial suggestions.

SECTION 6.2.2 : Accessors (in 6.2 Element nodes)

dm:string-value(): it says "If the element type is xs:dateTime,
xs:date or xs:time, returns the original lexical representation
of the typed value recovered as follows...".  If it returns
the "original" lexical representation, why do you need to 
specify a way to "recover" it?  There is only one "original"
lexical representation, and the only way to get it back is to
save it so that it is available for this accessor.  But that
does not seem to be the intent.  In that case, don't call it
the "original" lexical represntation; call it something else,
or avoid calling it anything, just say "here's what you do...".

Accepted editorial suggestions.

SECTION 2.4: document order

First sentence: "A document order is defined among all the nodes 
used during a given query or transformation."  Good sentence;
you have not equated
the data model with a particular realization of it. 
Third sentence: "Informally, document order is the order returned 
by an in-order, depth-first traversal of the data model."  wrong!
What you mean is "traversal of the trees in an instance of the data model."

Accepted editorial suggestions.

SECTION 2.2: notation

First two sentences: "...we define a set of 
accessor functions to explain the data model. The accessors defined 
by the data model are shown with the prefix dm:."  In the first
sentence, "we" define the accessor functions.  In the second 
sentence, the "data model" defines the accessor functions.
I think the first sentence is correct (the humans writing the specification are defining the accessor
functions).  

As for the second sentence, you can either strike 
the phrase "defined by the data model", or you can decide that
the accessor functions are not merely an explanatory device that
is separate from the data model.  In the latter case, the 
accessor functions are simply part of the data model.  In that
case the second sentence should read "the accessor functions
of the data model...".  This is the attitude adopted later in 
this section, where it says "There are some functions in the 
data model that are partial functions."

Accepted editorial suggestions.

SECTION 2.2: Notation

In the 5th paragraph, we read that "some functions are partial functions", but that term is not further used in the specification.  While we have no doubt that the statement is accurate, we believe that it adds nothing to the other material in the 3rd, 4th, and 5th paragraphs.  In fact, it may have the undesired effect of causing readers of the specification to stop and attempt to determine why the statement is there. 

We suggest removing the sentence and rewording the remainder of the paragraph as required to account for that removal. 

Accepted editorial suggestions.

SECTION 1, et seq: Introduction, et seq

The contents of this document are written in a mixture of first person
plural active voice (such as "we provide..."), which is more
appopriate for formal papers (e.g., research papers) than for
specifications, impersonal voice (such as "the implementation
provides" or "the term...is defined"), which seems more appropriate
for such specifications as this, and second person active voice
("For...see..."), which is also reasonably appropriate.

We suggest that the voice be consolidated into the second and third
forms (impersonal voice and second person active voice). While we
recognize that making this change should not hold up further
advancement of the specification, it seems appropriate to remove the
use of first person grammar on an opportunistic basis and on a
gradual, but deliberate, schedule.

Accepted.

SECTION : No particular section

The typographical convention of embedding (formal) definitions within
paragraphs, enclosed in square brackets, and introduced by
"Definition:" seems insufficiently attention-getting. Setting each
definition in a paragraph of its own would draw readers' attention to
it more readily. If this is viewed as inappropriate, then we suggest
that the introductory characters "Definition:" be typographically
highlighted, perhaps by setting them in boldface or in a slightly
greater point size.

(Incidentally, this comment applies to several of the XQuery documents.) 

Left to the editor’s discretion. Closed.

SECTION 3: Data Model Construction

The paragraph before 3.1 refers to 'well-formed document fragments',
what is this ?
The words 'well-formed', 'fragments', 'document' are overloaded in XML.
Please define them exactly here.

Accepted editorial suggestions.

SECTION C : Glossary

In the Glossary, it defines fragment as a tree whose root node is
some other kind of node. But it does not define what 'some-other kind
of node' is.  This definition is pulled from '1 introduction' section,
but the context is missing. 'some-other kind of node' really means
'non-root node' here.

Accepted editorial suggestions.

SECTION 1: introduction

In "1 introduction", there is a definition of fragment as "A tree
whose root node is some other kind of node is referred to as a fragment".

However, there is no reference to 'fragment' throughout the 
spec, so why there is a need to define 'fragment' ?  Are there any
other XQuery specs that refer to the definition of 'fragment' ?

Accepted editorial suggestions. (Fragment is now referenced.)

SECTION 6.2.1 : Overview (of element nodes)

Point 10 in the list of constraints on elements nodes says:
"If an attribute node A has a parent element E, then A must be among
the attributes of E.  The data model permits attribute nodes without
parents.  Such attribute nodes must not appear among the attributes
of any element node."  And in 6.3.1 Overview (for attribute nodes)
constraint 2 is a duplicate of this constraint.

Consider the following pathological data set: two elements
E1 and E2 and one attribute A.  The attributes property for
both E1 and E2 lists A as the only attribute of these elements.
Attribute A lists E1 as its parent.  This data set meets all of 
the constraints quoted.  What is missing is a constraint that says 
that if A is an attribute of element E, then E is the parent
of A.  That is, you have a constraint on one direction of the 
pointers, but not on the other direction.

I believe namespace nodes have the same problem.

Accepted editorial suggestions. (Fragment is now referenced.)

SECTION 5: Accessors

5 Accessors
First sentence of second para says 
"In order for applications to be able to operate on instances
of the data model, the model must expose properties of the items
it contains... These are not functions in the usual sense,
they are not available for users or applications to call directly."
This passage uses the term "application" in two senses, the 
first a nonstandard sense and the second a standard sense.
Usually "application" refers a software program that a user writes,
whereas "implementation" or "processor" refers to the software 
component implementing a specification and 
supplied by a vendor as a platform for the user to build his
application.  This understanding of "application" works for the
second occurrence of "application" but not for the first.
Indeed, if we try to use the standard meaning of the term for
both occurrences, the passage appears to be contradictory.

I think what you mean by the first occurrence of "application"
is that you are viewing the data model as being realized by
a software layer which is distinguishable from the XQuery or
XPath processor.  From that perspective the XQuery or XPath
prcoessor is an "application" of the data model.  But if you 
view things that way, then the accessors are indeed functions
that are callable by the "application".

For the sake of readability, if you want to introduce a 
distinction between the data model layer and the XQuery or
XPath processor above it, you should introduce a third term,
keeping "applciation" for the end user.  Alternatively, you
could rewrite the first sentence as "In order for XQuery or
XPath processors to be able to operate..."

Accepted editorial suggestions.

SECTION 5.10: namespaces accessor

You don't specify the order of the namespace nodes. 
Is it intended that the sequence of namespace nodes is in
document order, as defined in section 2.4 "Document order",
or is it perhaps left as an implementation-dependent
order?  

Suggest: add "... in Document order" to the definition.

Accepted editorial suggestions.

SECTION 5.9: attribute accessor

You don't specify the order of the attribute nodes. 
Is it intended that the sequence of attribute nodes is in
document order, as defined in section 2.4 "Document order",
or is it perhaps left as an implementation-dependent
order?  

Suggest: add "... in Document order" to the definition.

Accepted editorial suggestions.

Data Model: editorial, minor

Fifth paragraph of section 2.5 refers to the Formal Semantics for the 
semantics
of SequenceType Matching.

If I remember correctly, the normative definition of it is in the 
XQuery specification.
Please redirect the reference to the normative document.

/ Daniela Florescu <danielaf@bea.com> was heard to say:
| Data Model: editorial, minor
|
| Fifth paragraph of section 2.5 refers to the Formal Semantics for the
| semantics
| of SequenceType Matching.
|
| If I remember correctly, the normative definition of it is in the
| XQuery specification.
| Please redirect the reference to the normative document.

The normative definition can't be in XQuery because it's shared by XPath.

I believe the normative text is in Section "3.4.4 SequenceType Matching"[1]
in the Formal Semantics.

The syntax of SequenceTypes is in the XPath document.

Please let us know if this explanation is satisfactory.

[1] http://www.w3.org/XML/Group/xsl-query-specs/xquery-semantics/shared-semantics.html#id-sequencetype-matching

Data Model: editorial, minor

Last paragraph before section 6.4. talks about xs:anySimpleType.
It should be replaced by xdt:untypedAtomic

/ Daniela Florescu <danielaf@bea.com> was heard to say:
| Data Model: editorial, minor
|
| Last paragraph before section 6.4. talks about xs:anySimpleType.
| It should be replaced by xdt:untypedAtomic

Thank you. This has been fixed.

Data Model: editorial

The specification does not specify what is the type value of an
Infoset only processed attribute.

/ Daniela Florescu <danielaf@bea.com> was heard to say:
| Data Model: editorial
|
| The specification does not specify what is the type value of an
| Infoset only processed attribute.

The dm:typed-value accessor is described as follows:

dm:typed-value

    Returns the value calculated as follows:

        * If the attribute has a type of xdt:untypedAtomic, returns
          the string value of the node as an instance of
          xdt:untypedAtomic.

        * If the attribute has a simple type, returns a sequence of
          zero or more atomic values derived from the string-value of
          the node and its type in a way that is consistent with XML
          Schema validation.

          For xs:dateTime, xs:date and xs:time, the typed value is the
          atomic value that is determined from its tuple
          representation as described in 3.3.4 Retreiving the Typed
          Value of xs:dateTime, xs:date, and xs:time Values.

From section 6.3.3, the type of an attribute constructed from an infoset
is defined as:

type

   * If the [attribute type] property has one of the following
     values: ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, or
     NMTOKENS, an xs:QName with the [attribute type] as the local
     name and "http://www.w3.org/2001/XMLSchema" as the namespace
     name.

   * Otherwise, xdt:untypedAtomic.

This appears complete to me, what do you think is missing?

Overtaken by events.

Data Model: editorial

The specification does not specify what is the type value of an
Infoset only processed attribute.

Duplicate of qt-2004Feb0435-01.

Data model: editorial, minor

Section 6.2.2 accessor dm:string-value(), third bullet is unclear.

* If the element has a simple type or a complex type with simple 
  content:
    o If the element type is xs:string, or a type derived from xs:string, 
      returns that string.

Question: which string?

    o If the element type is xs:anyURI, returns the characters of the URI.

Question: which characters ?

    o If the element type is xs:QName returns the value calculated as follows:
        + If the value has no namespace URI and the in-scope namespaces map the 
          default namespace to any namespace URI, then an error is raised 
          ("default namespace is defined").

Question: what happens if the value has no namespace URI and there is 
no default namespace in scope?

The spec has been significantly redrafted in this area and we believe your concern has now been addressed.

Data model: editorial, minor

section 2.2. mentions parent as an example of partial function.
That's a wrong use of the mathematical concept of partial function.
A partial function is undefined on a subset of the domain (and expected 
to raise
errors on this subset), while the parent function does return values on
all the nodes. It is true that sometimes the result is the empty 
sequence, but this
doesn't make it a partial function.

/ Daniela Florescu <danielaf@bea.com> was heard to say:
| Data model: editorial, minor
|
| section 2.2. mentions parent as an example of partial function.
| That's a wrong use of the mathematical concept of partial function.
| A partial function is undefined on a subset of the domain (and
| expected to raise
| errors on this subset), while the parent function does return values on
| all the nodes. It is true that sometimes the result is the empty
| sequence, but this
| doesn't make it a partial function.

I don't think the phrase "partial function" actually adds any value to
the explanation. I've reworded it as follows:

<p>There are some functions in the data model that return the empty sequence
to indicate that no value was available.
We use the occurrence indicators <emph>?</emph> or
<emph>*</emph> when specifying the return type of such functions.
For example, a node may have one parent node or no parent.
If the node argument has a parent, the
<function>parent</function> accessor returns a singleton sequence.  If the node
argument does not have a parent, it returns the empty sequence.
The signature of <function>parent</function> specifies that it returns
an empty sequence or a sequence containing one node:</p>

Please let me know if this satisfies your concern.

Yes, it does. thank you.

Just a few comments for your Last Call Working Drafts [1,2,3,4,5,6].
They are on the whole absolutely beautiful and look like Recs not
Working Drafts. I hope this works for you to have comments grouped
in one email.

Functions and Operators and XPath, XQuery, Serialization (mentions the
RFC, thanks) need conformance sections and RFC 2119 keyword markup.
Data Model and XSLT have a good start. I am not 100% sure that span
class="verb" and strong in those is definite and specific enough.

I would match all tables to cellpadding="3" in the (X)HTML. XSLT uses 5
which is fine too. XSLT and one table in XPath and XQuery (precedence
order) need table summaries.

In the references sections in Functions and Operators [2], XPath [3],
Query [4], Serialization [5] and XSLT [6] the title of the work needs
to be the link, not the URI. Dominique Hazaël-Massieux wrote a
Bibliography Extractor that can help, and the Manual of Style has an
example entry to follow:

http://www.w3.org/2002/01/tr-automation/tr-biblio-ui
http://www.w3.org/2001/06/manual/#ref-section

Because the headings are so uniformly capitalized (this is great), the
exceptions stand out. I would capitalize the heading (and TOC items) in
Functions and Operators chapter 17, XQuery A.2, and "using" and
"arguments" in XSLT.

XSLT would be 200k smaller run through Tidy with indent off. Functions
and Operators would be 260k smaller (by something like 25%). The others
look right.

In Data Model
s/Retreiving/Retrieving/

  [ Fixed in DM 17 Feb 2004 ]

[1] http://www.w3.org/TR/2003/WD-xpath-datamodel-20031112/
[2] http://www.w3.org/TR/2003/WD-xpath-functions-20031112/
[3] http://www.w3.org/TR/2003/WD-xpath20-20031112/
[4] http://www.w3.org/TR/2003/WD-xquery-20031112/
[5] http://www.w3.org/TR/2003/WD-xslt-xquery-serialization-20031112/
[6] http://www.w3.org/TR/2003/WD-xslt20-20031112/

Accepted editorial suggestions.

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

The draft is at

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

Section 1 para 5:

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

Section 2.3:

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

Section 3 para 6:

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

Section 3.3 para 1:

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

Accepted editorial suggestions.

Section 3.3.4:

Typo - "Retreiving" should be "Retrieving".

  [ Fixed in DM 17 Feb 2004 ]

Accepted editorial suggestions.

Section 5.3:

The list of mode kinds names omits "namespace".

Accepted editorial suggestions.

Section 6.1.3 (and elsewhere):

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

Accepted editorial suggestions.

Section 6.1.3 under "children":

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

Accepted editorial suggestions.

Section 6.3.4 under "type":

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

Accepted editorial suggestions.

Section 6.4.3 under "parent":

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

Accepted editorial suggestions.

1.5 Imported schema

In section 2.5,

"The data model uses expanded-QNames to represent the names of named types,
which includes both the built-in types defined by [Schema Part 2] and named
user-defined types declared in a schema and imported by a stylesheet or
query."

"[Definition: An anonymous type name is an implementation defined, unique
type name provided by the processor for every anonymous type declared in an
imported schema.] "

- Does the word "import" here have the same meaning as used/defined in
section 4.2.3 of the schema structure spec?
- If not, its meaning should be made clear. If yes, why we only care about
imported schemas, but not the "importing" schema?
- The first sentence indicates that types are imported; the second
indicates that a schema is imported. Is there any difference?

Proposed fix: if there is no particular reason to include the word
"imported" here, we suggest to remove it. So the first sentence reads "...
declared in a schema." And the second reads "... declared in a schema.]"

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

1.6 Validate vs. assess

In section 3.3

"An instance of the data model can be constructed from a PSVI that has been
strictly, laxly, or skip validated or validated using any combination
assessment modes."

- PSVI is an augmentation to the base infoset, so I don't believe the it's
VALIDATED. (Probably GENERATED.)
- Do the phrase "strictly/laxly/skip validated" have special meanings that
are not defined in the schema spec? Are they different from
"strictly/laxly/not assessed" from the schema spec?

Proposed fix: if there is on particular reason to introduce such
difference, and more importantly, to align with the schema spec, we suggest
something along the following line:

"An instance of the data model can be constructed from a PSVI, whose
element and attribute information items have been strictly assessed, laxly
assessed, or have not been assessed."

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

1.7 xsi attributes

In section 6.3.4

"They will be validated appropriately by schema processors and will simply
appear as attributes of type xs:anySimpleType if they haven't been schema
validated."

- Editorial note: "They will be validated ..." and "if they haven't been
schema validated" sound like contradict to each other.
- These attributes are just ordinary attributes in schema, and they have
their declarations and types. Proper PSVI are available for them, so there
is no need to treat them differently. And of course, "xs:anySimpleType"
doesn't apply.

Proposed fix: to remove the above sentence.

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

2.2 Text nodes in document node

In section 6.1.3, for "children" property

"For each element, processing instruction, comment, and maximal sequence of
adjacent character information items found in the [children] property, a
corresponding element, processing instruction, comment, or text node is
constructed and that sequence of nodes is used as the value of the children
property."

But character information items are not supposed to appear in the
[children] property of a document information item.

Proposed fix:
- change "comment, and maximal sequence of adjacent character information
items" to "and comment", and
- change "comment, or text node" to "and comment".

Dupliate of qt-2004Feb0297-07

2.5 Missing constraints

[Section 6.3.1]

"2. If a attribute node A has a parent element E, then A must be among the
attributes of E."

In previous section, the rules go both ways. To be consistent, we need to
insert a new rule before this one.

"2. If an attribute node A is among the <b>children</b> of an element E,
then the <b>parent</b>of A <b>must</b> be E."

[Section 6.4.1]

"2. If a namespace node N has a parent element E, then N must be among the
namespaces of E."

Same comments as above.

[Section 6.7.1]

The first rule about unique identity seems to be missing. Is this intended?

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

2.6 "--" in comments

In section 6.6.1

"2. The string "--" must not occur within the content."

But it's possible to have "--" in the content of comments using
entity/character references.

Proposed fix: to remove this constraint.

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

2.15 Errors in the big example

In appendix D, I only took a quick look at the first few nodes, and spotted
some problems.

- For PI node P1, "dm:typed-value" is missing.
- For element node E1, why dm:type(E1) = xs:anyType? Shouldn't an anonymous
type name be generated?
- For comment node C1, "dm:typed-value" should have a value
- Also for comment node C1, "dm:type" is missing.

My guess is that there are more problems in the following nodes.  Was this
generated by some program or written by hand?

3. Editorial notes

3.1 Values vs. sequences

There are places in the DM draft where the relation between values and
sequences is not clear enough.

[Section 1]

"Every value in the data model is a sequence of zero or more items."
"An atomic value encapsulates an XML Schema atomic type and a corresponding
value of that type."
"A sequence cannot be a member of a sequence."

The combination of the above sentences is at worse contradictory, and at
best misleading. An atomic value is a value; a value is a sequence; a
sequence can't contain another sequence. The result is that an atomic value
can't be a member of a sequence, which clearly isn't the intention.

I don't have a better wording for the first sentence. But I think its
intention is clear from other parts of the spec, and it wouldn't be a
disaster to simply drop the first sentence.

[Section 2.2]

Related to a previous comment [7].

[7] http://www.w3.org/XML/Group/2003/08/xmlschema-datamodel-comments#d0e325

"Some accessors can accept or return sequences."

Aren't all values sequences? So "can" isn't accurate. It gives the
impression that some other accessors "can" accept or return things other
than sequences.

Suggested fix: drop the word "can".

[Section 2.2]

"The following notation is used to denote sequence values:
* V* denotes a sequence of zero or more items of type V.
* V? denotes a sequence of exactly zero or one items of type V.
* V+ denotes a sequence of one or more items of type V."

It seems to me "only" the above 3 forms are used to denote sequence values.
But from my understanding of the spec, "V" also denote a sequence (of
length 1).

Suggested fix: add the following as the first item:

"* V  denotes a sequence of one item of type V."

[Section 3]

"The data model also supports values that are not nodes. Examples of these
are atomic values, sequences of atomic values, or sequences mixing nodes
and atomic values."

Since values in the data model are all sequences, it's not appropriate to
list "atomic values" as an example.


3.2 Accessors applicable to one node type

In section 5.11

"It is defined on all seven node types, but always returns the empty
sequence for all nodes except elements."

(Where "it" refers to the "nilled" accessor.)

- The same statement is true for another 2 accessors "attributes" and
"namespaces": they only have values for elements. Why there aren't similar
notes for those 2 accessors?
- These 3 kinds of accessors only apply for elements. Then why having them
here (defined on all seven node types), instead of just having them on
element nodes?

The spec has been significantly redrafted in this area and we believe your
concern has now been addressed.

3.3 Referring to accessors and property values

There are occurrences of phrases like "the parent of N", "among the
children of N", "the string-value of N", etc., where it's not clear whether
"parent/children/string-value" refer to a certain property of a node, or
the returned value of a certain accessor.

Either way, it needs to be clarified. If the intention is to refer to
property values, then they should be in bold font; if the intention is to
refer to accessors, then such convention should be made clear somewhere

Data Model Section 3.3.1 (Mapping PSVI Additions to Types): This section 
needs to specify how the type xs:anyType in the PSVI is mapped into 
xdt:untyped in the Data Model, and xs:anySimpleType in the PSVI is mapped 
into xdt:untypedAtomic in the Data Model.

In the Data Model document, all occurrences of xdt:untypedAny should be 
changed to xdt:untyped, throughout the document.

Accepted editorial suggestions.

Data Model Section 5.2 (node-kind Accessor): Claims to be defined on seven 
node types but provides only six possible return values ("namespace" is 
omitted).

Accepted editorial suggestions.

Data Model Section 6.1.3 (Document Nodes--Construction from an Infoset): 
This section specifies how three of the four properties of a document node 
are derived from an infoset. It should also mention the fourth property, 
"document-uri", and state that it is derived from the absolute URI of the 
resource from which the document node was constructed, as described under 
"Accessors".

Decided at BEA face-to-face: agreed to clarify (duplicate of qt-2004Feb0707-01).

Data Model Section 5.10 (namespaces Accessor): The result type 
namespace()* is not a valid SequenceType. Should be changed to node()* 
with an explanation that the nodes returned are namespace nodes.

Accepted editorial suggestions.

Data Model Section 6.4.2 (Namespace Nodes--Accessors): The dm:typed-value 
accessor claims that its return type is xdt:untypedAtomic. This should be 
changed to xs:string.

Agreed.

Data Model Section 6.2.3 (Element Nodes--Construction from an Infoset): 
Under "namespaces" we see that an implementation may ignore namespace info 
items for namespaces that do not appear "in the expanded QName of any 
element or attribute info item". This should be clarified to state "in the 
expanded QName of the current element or any of its attributes." 
Presumably the infoset-to-data-model mapping for a given element should 
not depend on whether a namespace has been used in the name of some other 
element.

Accepted editorial suggestions.

Data Model Sections 6.5.3 and 6.6.3: Section heading should be 
"Construction from an Infoset" in each case.

Accepted editorial suggestions.

Data Model Section 6.2.2 (Element Nodes--Accessors): The dm:string-value 
and dm:typed value accessors have some problems with terminology. Both 
accessor descriptions refer to "complex type with complex content" but 
this terminology is not found in XML Schema. In XML Schema, a complex type 
may have empty content, simple content, mixed content, or element-only 
content. The accessor descriptions should use these terms rather than the 
undefined term "complex content". For an example of how to do this, see 
Section 2.4.2 (Typed Value and String Value) in the language document, 
which the Data Model description should be consistent with in any case.

Accepted editorial suggestions.

Data Model Section 8 (Sequences): I suggest deleting the last paragraph of 
this section, which deals with how to compare sequences. Sequences can be 
compared in various ways. In any case, this material belongs in the 
Functions and Operators document.

Accepted editorial suggestions.

Data Model Appendix C (Glossary): The definition of "fragment" reads, in 
its entirely, as follows: "A tree whose root node is some other kind of 
node is referred to as a fragment." This definition does not stand by 
itself.  "Some other kind of node" should be changed to "not a document 
node".

Accepted editorial suggestions.

Data Model Appendices E, F, and G are very long and completely redundant 
to material that has already been presented elsewhere. I think these 
appendices should be deleted. Deleting them will eliminate 16 pages (out 
of 78 total) without any loss of content.

They provide a concise, useful summary and are generated automatically (so there’s
no danger of them getting-of-sync. Proposal: reject.

Data Model Sections 6.6.1 (Comment Nodes--Overview) and 6.7.1 (Text 
Nodes--Overview): The parent property should specify "possibly empty" in 
each case.

Accepted editorial suggestions.

Data Model Section 7 (Atomic Values): The fifth paragraph contains a 
bullet list that talks about the "value of a node" and how it is 
"represented". This material belongs in the sections on element and 
attribute nodes, since these are the kinds of nodes that have values, and 
they represent them in different ways. But the terminology in these 
bullets is inconsistent with the rest of the document. Element and 
attribute nodes have various properties, but none of these properties are 
named "value". For example, an element node has "children", and an 
attribute has a "string value". But neither of these properties has the 
appropriate type for these rules. Perhaps these rules are trying to 
explain how the typed value of an element node is derived from the content 
of its child text nodes? Or how the typed value of an attribute node is 
derived from its "string value" property? In any case, the terminology of 
these rules needs to be fixed and the rules need to be moved to the 
appropriate section.

The section on types and atomic values has been extensively redrafted to
address this and other similar comments.

David Carlisle wrote:
> There is also the issue of whether the DM should disallow a trailing -
> currently it only disallows --.

This new Last Call comment will ensure that the apparent inconsistency
between the DM and the rules for comment construction in XQuery and XSLT
is resolved.

/paulc

Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 
mailto:pcotton@microsoft.com

  

> -----Original Message-----
> From: David Carlisle [mailto:davidc@nag.co.uk]
> Sent: January 21, 2004 3:51 PM
> To: Paul Cotton
> Cc: public-qt-comments@w3.org
> Subject: RE: [Xquery] Comment constructors
> 
> 
> That addresses my comment on the Xquery constructors thanks.
> There is also the issue of whether the DM should  disallow a trailing
-
> currently it only disallows --.
> 
> David
> 
> 
> --
> http://www.dcarlisle.demon.co.uk/matthew

    

Accepted editorial suggestions.

Appendices E, F, G 
Editorial	

I hope these appendices are generated automatically for consistency.
Otherwise, please remove these appendices to avoid inconsistencies.

Accepted editorial suggestions.

Appendix D Examples	
Editorial
	
Make sure that all type annotations are correct (e.g., xs:anySimpleType
should be xdt:untypedAtomic)

    

Appendix B References	
Editorial	

Shouldn't the XPath 2.0 document be referenced normatively since it is
being used by the new types in section 7?

    

Accepted editorial suggestions.

Section 7.1	New Datatypes
Editorial	

Add a new section header 7.1 for the first part, so that there is more
than one second-level section.

Accepted editorial suggestions.

Section 7.1	New Datatypes
Editorial

Move introduction of the data types to section about type system (see
comment MS-DM-LC02-026/7).

The section on types and atomic values has been extensively redrafted to
address this and other similar comments.

Section 7 Atomic Values	
Editorial	

"xs:untypedAtomic" -> "xdt:untypedAtomic"

Accepted editorial suggestions.

Section 7 Atomic Values	
Editorial	

"The value space of the atomic values ": How can a value have a value
space. Types have value spaces. Did you mean "The value space of
xdt:anyAtomicType"?

The section on types and atomic values has been extensively redrafted to
address this and other similar comments.

Section 7 Atomic Values	
Editorial	

"xdt:anyAtomicType" is not a primitive type. It is an abstract type
which  cannot be a value's direct type.

The section on types and atomic values has been extensively redrafted to
address this and other similar comments.

Section 7 Atomic Values	
Editorial	

"Types derived by list or union are not atomic.": Place outside
definition.

Accepted.

Section 6.7.3 Construction from an Infoset	
Editorial	

"W3C normalized" has been renamed to "fully normalized". There are also
other normalization forms that may be interesting for an application.
Just say that text nodes are not necessarily normalized. Also, the term
"programmers" should be defined (implementers of the data model or
somebody that writes Xqueries or XSLT stylesheets?)

Accepted editorial suggestions.

Section 6.7.3 Construction from an Infoset	
Editorial	

"Applications may construct text nodes in the data model to represent
insignificant white space. This decision is considered outside the scope
of the data model, consequently the data model makes no attempt to
control or identify if any or all insignificant white space is ignored."
XQuery considers all text nodes in the data model to be significant
(does not generate them if they are not significant). Do we thus still
need this paragraph?

White space is explicitly significant except in element-only content.

Section 6.7.2 Accessors	
Technical	

dm:type() should return () as for comments, PI. There is no way to set
or ask the type for text nodes and the typed-value is defined to be of
type xdt:untypedAtomic.

Accepted editorial suggestions.

Section 6.5.3 Processing Instruction Information Items	
Editorial	

Title of section should be "Generation from Infoset".

Accepted editorial suggestions.

Sections 6.5.1/6.6.1 Overview	
Technical/Editorial	

We should either disallow ?> in PI content, or not talk about -- in
6.6.1 and move this to serialization. In order to provide XSLT
backwards-compat, this should be moved to the serialization spec.

Accepted editorial suggestions.

Section 6.3.4 Construction from a PSVI	
Technical	

The xsi attributes should not be typed as xs:anySimpleType but according
to their specific type given by the schema rules for these attributes.

Accepted editorial suggestions.

Section 6.3.4 Construction from a PSVI	
Editorial	

"Infoset-only processing does not apply to subtrees that are "skip"
validated": Shouldn't this be "Infoset-only processing does apply to
subtrees that are "skip" validated"?

I don't think so. We don't apply infoset-only processing to any
document that has been schema validated. (If we did, you could get
weird inconsistencies due to the mixture of DTD-based attribute types
and schema-based attribute types, I think.)

Section 6.3.2 Accessors	
Editorial	

dm:string-value(): see comment MS-DM-LC2-055 on 6.2.2. Also rule does
not have a fallback. What happens if we have xs:int?

Accepted editorial suggestions.

Section 6.3.4 Construction from a PSVI	
Editorial/Technical	

"any of its ancestors": Please clarify how this can happen.

Accepted editorial suggestions.

Section 6.2.3 Construction from Infoset	
Editorial	

nilled: Should be referring to section 3.3.2 instead of repeating the
rules

Accepted editorial suggestions.

Section 6.2.3 Construction from Infoset	
Editorial/Technical	

"This can arise when xs:Qname are used in content": Since we are talking
about Infoset, please do not use xs:QName, instead talk about QNames
instead.

Accepted editorial suggestions.

Section 6.2.3 Construction from Infoset	
Editorial	

Enumerate all special attributes and not only a few.

I'd rather not. As it's worded now, it will apply equally well if
someone adds a new "special" attribute in the future.

Section 6.2.2 Accessors	
Editorial	

Clarify whether the in-scope namespaces used for the xs:Qname
serialization are in the static or dynamic context (We hope the static
context).

    

Section 6.2.2 Accessors	
Editorial	

Why do we special case of some types but not others? Does not the rule
about text nodes of simple-typed values and other previous sections
(3.3.4) cover them?

Accepted editorial suggestions.

Section 6.2.1			
Editorial

Similarly to other sections, only constraints 2, 6 and 7 are new.  The others are redundant with previously mentioned constraints. Please rewrite the constraints to identify normative part and factor common constraints.

Common constraints have been factored out to the top of section 7.

Section 6.1.3 Construction from Infoset	
Editorial	

Correspondence between maximal sequence of adjacent CII and text node
needs to be made more rigid.

    

Section 6.1.2 Doc Nodes 	
Editorial	

Entity properties are only useful if DTD processing is being done. Make
clear that last para in 6.1.1 refers to these two properties.

Accepted.

Section 6.1.2 Doc Nodes 
Editorial/Technical	

What about dm:string-value if it has not text node descendent. Add that
you get "" (zero-length string).

Accepted editorial suggestions.

Section 5.2	node-kind Accessor	
Editorial/Question	

Is this accessor still needed? We removed the similar function from F&O.

Removed.

Section 5		
Editorial	

"Some node kinds have additional accessors that are not summarized
here." What and where are they? Either remove sentence or clarify.

Accepted.

Section 5	All subsections	
Editorial	

Replace "node types" with "node kinds".

Accepted editorial suggestions.

Section 5.10 namespaces Accessor	
Editorial	

Please clarify that this accessor returns the dynamic in-scope namespace
nodes (and not the namespace nodes defined by the element).

    

Section 3.3.2 Mapping xsi:nil on Element Nodes
Editorial

Please add a note that the attribute is also preserved as a queryable
attribute. The current wording could be interpreted as that this is not
the case.

Accepted editorial suggestions.

Section 6 Nodes	
Editorial	

Replace the first two sentences by: [Definition: The seven distinct
kinds of nodes document, element, attribute, text, namespace, processing
instruction, and comment] are defined in the following subsections.

Accepted editorial suggestions.

2.2.1 Prefix Bindings lists some, but not all.

dm: is used prior to a definition.

Accepted editorial suggestions.

Section 5.2 lists out 6 possible values that the node-kind accessor
can return. The "namespace" value is missing from this list.

Regards,
Kenneth Stephen

Accepted editorial suggestions.

The DM spec contains three occurrences of "as document()" that should be "as
document-node()".

Accepted editorial suggestions.

Section 3.3	Construction from a PSVI	
Editorial	

lexical form of elements and attributes with atomic types: clarify that
this affects values, PIs and comment handling.

I believe this has been clarified..

Section 3.2	Construction from an Infoset	
Editorial	

Strike the sentence starting "Constructing and". The meaning is unclear.

/ Michael Rys <mrys@microsoft.com> was heard to say:
| Section 3.2	Construction from an Infoset	
| Editorial	
|
| Strike the sentence starting "Constructing and". The meaning is unclear.

Accepted. That sentence now reads:

<p>An instance of the data model constructed from an information set
<rfc2119>must</rfc2119> be consistent with the description provided
for each node type.</p>

Please let me know if this resolves the issue to your satisfaction.

Section 3.2	Construction from an Infoset	
Editorial	

Use "node kind" instead of "node type" as consistent terminology
throughout the document.

Accepted editorial suggestions.

Section 2.5	Types	
Editorial	

Add more precise reference to value/type matching in Formal Semantics
spec.

Accepted editorial suggestions.

Section 2.5	Types	
Editorial	

Clarify sentence about unknown types. Does this mean
xs:anyType/xs:anySimpleType or xdt:untyped/xdt:untypedAtomic?

Accepted editorial suggestions.

Section 2.5	Types	
Technical/Editorial	

"The item is guaranteed to be an instance of this type": Not really. It
an instance of the node kind of the given type.

Accepted editorial suggestions.

Section 2.5	Types	
Editorial	

Also mention the XPath/XQuery types (the xdt-types). Move section 7.1
here.

The sections on types and atomic values have been extensively redrafted to
address this and a number of other similar comments.

The SOAP WG has decided to adopt the XQuery Data Model for its Message
Transmission Optimization Mechanism (MTOM). MTOM describes an optimization
mechanism for message transmission and "on-the-wire" format for SOAP
message which may refer to non-XML message parts. As part of the MTOM
design, members of the SOAP WG have used the XQuery Data Model
specification [1] and wished to make comments on the wording of the
document.

In particular, the SOAP WG has found it necessary to clarify our use of the
wording relating to Accessors in section 5 of [1] due to perceived
ambiguities when used wrt the xbinc:include element for MTOM:

Section 5.3 dm:node-name: It was not obvious from the Data Model
specification
what the syntax for this accessor should be. We eventually decided it
should be,
xs:Qname("http://www.w3.org/...../xbinc", "include") but this was only by
noticing
the example in Appendix D of the specification. We should probably have
read the
sections on Functions and Operators, but this was not obvious.

Section 5.4 dm:parent, the specification sates "Returns the value of the
parent property"
which is not a particularly useful description of the accessor. It is not
clear
from traversing the internal hyperlinks how one determines the parent of a
given node.

Section 5.5 dm:string-value is fairly well specified for each node type
(sections 6.2.2, 6.3.2)

Section 5.6 dm:typed-value is also fairly well specified.

Section 5.7 dm:type, the description "Returns the vaue of the type
property" is not very useful.

Section 5.8 dm:children, once again, the description is not very useful.
The same problem exists
for many of the accessor descriptions in Section 6. Many of the
descriptions are of the form:
db:XXXX
"returns the value of the XXXX property"

A subsection of 6 (i.e., 6.1, 6.2, ...) should be read entirely to
understand the behaviour of
an accessor. For example, for Element Nodes, dm:children is defined as
"returns the value of the
children property" in 6.2.2. 6.2.1 defines some constraints over the
children property, but does
not define it. 6.2.3 and 6.2.4 specify own this property is constructed
from an Infoset or a PSVI.

Adding some links between those parts would be helpful to a reader. In the
case of dm:children
for Element Nodes, it would help to add a reference in the definition of
dm:children for Element
Nodes in 6.2.2 to the definition of children property in 6.2.1; and also to
add some text after
the listing of the Element Nodes' properties in 6.2.1 saying that building
those properties from
an Infoset of a PSVI is described in 6.2.3 and 6.2.4.

We will put a note in the MTOM spec to invite comments on or use of the
XQuery Data Model.

[1] http://www.w3.org/TR/xpath-datamodel/

John Ibbotson
CEng FIEE

Emerging ebusiness Industry Architecture ,
XML Technology and Messaging,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com

Section 2.3	Node Identity
Editorial

Add normative clarification that atomic values and sequences do not have
identity.

Accepted editorial suggestions.

Section 2.4	Document Order
Editorial

Make term "stable" bold and a defined term.

Accepted editorial suggestions.

Section 2.3	Node Identity
Editorial

"This Concept" -> spell out: Identity. Also make this sentence a note.

Accepted editorial suggestions.

Section 2.3	Node Identity
Editorial

"Data model is a node-labeled, directed graph" vs "Data model is
sequence" in section 1. Section 1 suffices. Remove first sentence and
beginning of second sentence to "in which".

Accepted editorial suggestions.

Section 2.2	Notation
Editorial	

Move description of pseudo-prefix dm: closer to section 2.2.1 in order
to show the relationship and differences.

Accepted editorial suggestions.

Section 2.2	Notation
Editorial	

URI for fn: needs to be updated to correct version.

Accepted editorial suggestions.

Section 2.2	Notation
Editorial	

expanded-Qname is a term and not a notation. Please fix section header
or move to a term section.

Accepted editorial suggestions.

Section 2.2	Notation
Editorial	

The data model also relies on PSVI. Do we have special notations in that
context?

Clarified.

Section 2.2	Notation
Editorial	

Stratify the subheaders of 2.2. Add one per concept.

Accepted editorial suggestions.

Section 2.2	Notation
Editorial	

Remove sentence about partial functions. Term is never used and is
misleading since the functions are not truly partial (they always return
something). Reword the paragraph as a for example.

Accepted editorial suggestions.

Section 2.2	Notation
Editorial	

What does the sentence "In a sequence ..." actually mean? V is a type
after all...

Accepted editorial suggestions.

Section 2.2	Notation
Editorial	

"Some accessors to atomic value" needs to be replaced with a reference
to the function signature definition and explanation of the SequenceType
production in the XQuery/XPath document.

Clarified with reference to the F&O document.

Section 2.2	Notation
Editorial	

"cannot be made accessible": Clarify: either "should not" or "must not",
or "cannot because no namespace is associated with the prefix".

Accepted editorial suggestions.

Section 2.1	Terminology
Editorial	

Use a consistent definition of imp-defined/imp-dependent across all
documents. This is currently not the case. We prefer the definition
given in the XQuery language specification.

I believe these changes have been made.

Section 2.1 Terminology
Editorial

What are paragraphs that are not labeled? Are they all normative? Please
clarify.

Clarified.

General (also applies to other specifications)
Editorial

The specifications currently use the term value in a somewhat ambiguous
way. Sometimes it implies "atomic value" (what most people associate
with this term), sometimes it implies "item", sometimes it implies
"sequence of items".

Since we believe that most spec readers understand "atomic value" when
they read "value", we propose that the specs should not use the term
value. Use item, node, atomic value and sequence thereof as appropriate
instead.

The terms value and type have been clarified in this draft.

Section 1 Introduction
Editorial

The data model relates to values in the Infoset _and_ PSVI.

Accepted editorial suggestions.

Section 1 Introduction
Editorial

Change "Property of nodes" to "property of items".

Accepted editorial suggestions.

Section 1 Introduction
Editorial

Remove note about XPath 1.0 data model since it is controversial. Some
people disagree with this assessment and it only leads to confusion.

Accepted editorial suggestions.

Section 1 Introduction
Editorial

Atomic values do not only encapsulate XSD types but also XQuery types
such as xdt:untypedAtomic. Please fix this.

Accepted editorial suggestions.

Section 1 Introduction
Editorial

"Connected": drop word or define it. 

Also move third sentence in paragraph into second position.

Accepted editorial suggestions.

Section 1 Introduction
Editorial

The term "kind" needs to be a defined term.

This section has been edited to make it clear that “kind” is only meant in the
normal English-language sense.

Section 1 Introduction
Editorial

Add definition of term item here or move this whole part into the
concept definition section.

I believe these changes have been made.

Section 1 Introduction

Editorial

Add sentence that every value has a type. The term type also needs to
have a definition.

I believe these changes have been made.

I think that every place the Data Model draft says "complex content", it
means "element-only content".  I say this because I believe "complex
content" includes both "element-only content" and "mixed content".  For
example, when describing the typed-value accessor of element nodes, it says:

"If the node has a complex type with complex content, raises a type
error..."  

but mixed content was covered by an earlier point.  

Thanks,
Priscilla

Accepted editorial suggestions.

1.2. Derivation of simple types

    Section 5 Atomic Values reads in part:

      An XML Schema simple type [XMLSchema Part 2] may be primitive or
      derived by restriction, list, or union.

    We think it will help avoid confusion among users, implementors, and
    (not least) discussion among Working Groups if you use XML Schema
    terminology here. Perhaps:

      An XML Schema simple type definition [XMLSchema Part 2] has a
      [variety], which may be atomic, list or union. If [variety] is
      atomic, the type definition may be primitive or derived by
      restriction.

    The XML Schema WG wishes to de-emphasize the use of the term "derived
    by" in XML Schema Part 2 in describing union and list contruction. The
    term "derived by" is used only colloquially there and is unfortunately
    confused with derivation in the proper sense (i.e. restriction and
    extension). All non-primitive simple types are derived by restriction.
    List types may be restrictions of xs:anySimpleType or other lists.
    Similarly for union types. Please don't propagate the confusion we
    created.
    [We are aware that it would be useful to have a simple term other than
    derivation to describe the relation between a list type and its item
    type, or that between a union type and its member types; we need it as
    much as you do. Suggestions are welcome.]

The section on types and atomic values has been extensively redrafted
to address this and a number of other related comments.

1.6. Target namespaces

    Section 3.4 Types reads in part:

      Since named types in XML Schema are global, an expanded-QName
      uniquely identifies such a type. The namespace name of the
      expanded-QName is the target namespace of the schema and its local
      name is the name of the type.

    A schema does not have a target namespace; a schema document has a
    target namespace.
    One possible repair would be:

      Since named types in XML Schema are global, an expanded-QName
      uniquely identifies such a type. The namespace name of the
      expanded-QName is the {target namespace} property of the type
      definition, and its local name is the {name} property of the type
      definition.

    Another might be:

      Since named types in XML Schema are global, an expanded-QName
      uniquely identifies such a type within a schema.

    We believe this to be relatively important.

Accepted editorial suggestions.

1.7. Lexical spaces, reference, containment

    Section 2 refers to: "the lexical space referring to constructs of the
    form prefix:local-name". Perhaps substitute "the lexical space
    containing ..." Lexical forms may, with a certain investment of time
    and energy, be thought of as `referring to' values, but the lexical
    space as a whole does not refer. The lexical space of QName does
    contain, even if it does not refer to, constructs of the form
    prefix:local-name.

Accepted editorial suggestions.

2.1. Atomic values and singleton sequences

    In section 2 Notation, after indicating how to represent Node and Item
    in the syntax, DM says "Some accessors can accept or return
    sequences."
    This may need clarification; elsewhere we had been led to think that
    everything is a sequence. Please emphasize that Node, Item, and atomic
    values in the syntax correspond to singleton sequences, and that some
    accessors accept less-constrained sequences.
    Some members of the XML Schema WG add that DM seems to conflate the
    notations of list and sequence, which are distinct and should not be
    confused.

Accepted editorial suggestions.

2.2. Node identity

    Sections 3.1 and 3.2 raise the question of node identity and stable
    ordering.
    Does a node maintain its identity on being modified? on being added to
    another tree? If so, wouldn't its ordering change?

Rejected.

2.3. Names in namespace nodes

    Section 4.3 Elements lists, among the constraints that element nodes
    must satisfy:
    7. The namespace nodes of an element must have distinct names.
    This requirement contradicts the definition of dm:name for namespace
    nodes, for processors that choose not to preserve prefix information.
    All their namespace nodes will name [or have] the same name, namely
    the empty sequence.

Removed constraint as it’s not actually true.

2.5.1. Infoset-only processing

    Section 3.6 says, under the heading "Infoset-only processing":

      Note that this processing is only performed if no part of the
      subtree that contains the node was schema validated. In particular,
      Infoset-only processing does not apply to subtrees that are "skip"
      validated in a document.

    Which subtree is "the" subtree? A given node is contained by many
    subtrees. Perhaps read "if no part of any subtree containing the node
    was schema validated"?

Accepted editorial suggestions.

3. Editorial notes

    In the course of our work, some editorial points were noted; we list
    them here for the use of the editors. We do not particularly expect
    formal responses on these comments.

3.1. Comments reviewed by the Working Group

     1. QNames. Section 2 Notation reads in part:

      [Definition: An expanded-QName is a pair of values consisting of a
      namespace URI and a local name. They belong to the value space of
      the XML Schema type xs:QName. When this document refers to xs:QName
      we always mean the value space, i.e. a namespace URI, local name
      pair (and not the lexical space referring to constructs of the form
      prefix:local-name).]
        Thank you for being specific about value-space vs. lexical space.
        Please also be specific on whether the namespace URI can be absent
        or not.
     2. Section 3.3: The definition

      [Definition: A Post Schema Validation Infoset, or PSVI, is the
      augmented infoset produced by an XML Schema validation episode.].
        has an extra full stop at the end.
     3. Section 3.4 para 6:

      It returns xs:anyType or xs:anySimpleType if no type information
      exists, or if it failed W3C XML Schema validity assessment.
        Are "xs:anyType" and "xs:anySimpleType" expanded-QNames? They
        don't look like it.
     4. Section 4.1.1: We suggest using "[base-uri]" rather than
        "base-uri" when referring to the infoset propery, to avoid
        confusion with the base-uri accessor. In general, we believe all
        references to infoset properties should use the brackets.
     5. Section 4.1.3:

      dm:node-name returns the qualified name of the element or
      attribute.
        The XML Infoset does not define a [qualified name] for items. For
        "qualified name" perhaps read "expanded QName".
     6. Section 4.1.6, bulleted list: Two of the bullets begin "If the
        item is" and the rest begin "If the node is". Why are these
        different? At first we thought the difference reflected a crucial
        difference in the tests being performed, but the entire list is
        about nodes; there are no items under discussion which are not
        nodes.
     7. Section 4.3.2, repeated in 4.4.2: the first bullet item says that
        under certain circumstances the result will be an "atomic value
        3.14 of type decimal". Should that be "xs:decimal"?

I believe these changes have been made.