Re: I18N last call comments on XQuery/XPath Data Model

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This reply addresses editorial issues raised by the I18N LC1 comments

/ Martin Duerst <duerst@w3.org> was heard to say:
[...]
| [1] In general, this is a very extensive and rather boring document.
| Where possible, it should be shortened and compacted, to make it
| easier to get the relevant points.

The document has been extensively redrafted and is considerably shorter.

| [2] There are mappings between the following different things:
| - properties of nodes of the data model
| - the corresponding accessors
| - the mapping from the PSVI (post-schema validation infoset)
|    to the properties
| - the mapping from accessor output to XML infoset properties
| (in the other draft we are reviewing, there are also functions
| corresponding to the accessors).
|
| At least one of these could easily be removed (e.g.
| the properties or the accessors).

The mapping from the data model back to the infoset has been removed.

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

As a purely editorial matter, I disagree. The XSLT specification uses
the term stylesheet almost exclusively.

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

Yes.

| [5] 3.2 Document order: "The relative order of nodes in distinct
| documents is implementation-dependent but stable. In other words,
| given two distinct documents A and B, if a node in document A is
| before a node in document B, then every node in document A is before
| every node in document B.
|     The second sentence sounds like a corollary from the first, but is
|     a non sequitur. It could as well be that an implementation decides
|     to order first all the first nodes from all the documents, then all
|     the second nodes, and so on. If indeed all nodes of one document
|     have to be before all nodes of another document, that should be
|     said explicitly, and not only as 'in other words'.

The section on document order has been redrafted.

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

The WAI guidelines suggest the square bracket syntax. If you can
propose an alternate presentation that satisfies the WAI guidelines,
I'd be happy to entertain it.

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

This section has been redrafted.

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

The discussion of anonymous type names has been redrafted.

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

OK.

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

The accessor sections have been extensively redrafted.

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

The accessor sections have been extensively redrafted.

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

The accessor sections have been extensively redrafted.

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

OK.

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

The specification states explicilty that they may be ignored. If they
are ignored adjacent text nodes must be merged.

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

The accessor sections have been extensively redrafted.

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

The accessor sections have been extensively redrafted.

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

The xml:base attributes appear in the data model as normal attributes.

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

OK.

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

The accessor sections have been extensively redrafted.

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

This section has been redrafted.

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

This section has been removed.

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

The URI is property like the others. I think it would seem strange to
suggest a mapping at this point in the spec.

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

OK.

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

This section has been redrafted.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE/sk5dOyltUcwYWjsRApT7AKCR9dL7Ey+d0Nm+yWjKTDTUzRLOwQCgnc8E
awkKWde9FJVw6FogbGnMxLQ=
=KsCW
-----END PGP SIGNATURE-----

Received on Thursday, 13 November 2003 20:19:44 UTC