Re: XML Core WG comments on XQuery/XPath data model

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

This reply addresses editorial issues from the Core WG LC1 comments.

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

No, I'm pretty sure it's in-order. I'll be a bit embarrassed if I'm
shown to be wrong on this point, but...

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

The document has been reworded to avoid that term.

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

The mapping sections have been extensively redrafted. I believe this
is clearer now.

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

The WG understands that in some MIME multi-part cases, it is possible
for several documents to have thee same base URI and yet be distinct.

| "Invalid" infosets
| -------------------------
| [4.2.4] "the resulting Infoset may be invalid": the term "invalid" is
| not appropriate here.  For infosets that do not correspond to
| well-formed documents it would be better to call the infosets "not
| well-formed".
|
| The are more uses of "valid" in this sense elsewhere in the draft.

The sections that describe mapping to the infoset have been removed.

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

This text has been redrafted.

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

This text has been redrafted.

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

This accessor has been removed.

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

They cannot. Use an implementation that does not casually discard
namespaces.

| Errors in element mapping to infoset
| -----------------------------------
| [4.3.4] In the table, under [children], the value refers to the
| [namespace name] property instead of the [children] property.
|
| Under [namespace attributes], the value should be a sequence of
| attribute information items, not of namespace information items.

The sections that describe mapping to the infoset have been removed.

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

The sections that describe mapping to the infoset have been removed.

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

The sections that describe mapping to the infoset have been removed.

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

The sections that describe mapping to the infoset have been removed.

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

True.

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

This text has been removed.

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

Fixed.

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

Correct. I've clarified the wording.

                                        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/skpKOyltUcwYWjsRAmXyAJwK6rQOmsvzeqG7ptQn7wQuk/HiHACZATgP
Z5IuP2jh4GyN5q7Ai0TUf/E=
=KAaD
-----END PGP SIGNATURE-----

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