W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2005

[Bug 1293] New: [DM] Editorial comments from XML Core WG

From: <bugzilla@wiggum.w3.org>
Date: Tue, 03 May 2005 14:11:00 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DSy72-0008EG-71@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1293

           Summary: [DM] Editorial comments from XML Core WG
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Data Model
        AssignedTo: ndw@nwalsh.com
        ReportedBy: richard@inf.ed.ac.uk
         QAContact: public-qt-comments@w3.org


This i a list of the editorial and other trivial problems we found.
Our substantive comments will be recorded as separate items.

2.1, sentence beginning "Every node is one of"
"dm:namespaces" should presumably be "dm:namespace-nodes", and a link.

2.1, definition of expanded-QName
(typo) "empyt" should be "empty".

2.6.2, xdt:dayTimeDuration
"six lines" should be "nine lines".

3, sentence beginning "This document describes" (and elsewhere)
(style) Use "an infoset ([Infoset])" the first time and "an infoset"
thereafter, not "an [Infoset]".

3.3.1.3
This section explains what is meant by "consistent with schema 
validation".  It would have been useful to have a link to it when
the term was first used.  And in 2.6.4 the phrase "consistent with
validation" (not "schema validation") was used.

5.5, 5.6
"is an XML ID" is unclear.  Does it mean "has a value of type ID", or
"is an attribute with [attribute type] ID", or what?  Likewise for "is
an XML IDREF or IDREFS".  After reading section 6, it becomes clear
that this depends on what the data model is constructed from, but a
hint here would be useful.

5.12
Why is "parent" in bold?  Is it supposed to mean the parent property?
If so, it is inconsistent with the rest of section 5 which is giving
plain-English descriptions of the accessors, rather than defining them
in terms of node properties.  Contrast 5.1 and 5.3 which don't have
"attributes" or "children" in bold.

6.1.1, constraint 1
(typo) "namespace" should be capitalized.

6.2.1
The namespaces property is described as "possibly empty", but as noted in
constraint 13 it must contain a binding for the XML namespace.

6.2.3
This section is supposed to be about constructing from a plain
infoset, but the attributes and namespaces items refer to things that
only arise for a PSVI: attributes defaulted by schema processing,
values of type xs:QName.  Perhaps these should be moved to 6.2.4.

6.2.3, attributes property
"attributes's" should probably be just "attributes".

6.2.5, [attributes]
The [attributes] property is an unordered set, not a list.

6.7.3
[element content white space] should be [element content whitespace].

6.7.4
The statement that empty text nodes are discarded should not appear only
under contruction from a PSVI, since it applies equally to construction
from an infoset.

6.7.5, [element content whitespace]
"Unknown" should be in italics.

Appendix D, anonymous type name
The term "static context" is not defined (presumably it is defined
in one of the other specs).

Appendix D, expanded-QName
(typo) "empyt" should be "empty".

Appendix A
The [unparsed entities] property of Document infoitems is optionally used.
The [element content whitespace] property of Character infoitems is 
optionally used.
The [prefix] property of Element and Attribute infoitems is (optionally?)
required.
The [prefix] property of Namespace infoitems should not be optional.

Appendix D, instance of the data model
"Every instance of the data model is a sequence."  This is not really
a definition of "instance of the data model".  It makes more sense in
the Terminology section (2.1) where it is immediately followed by a
definition of "sequence", but here it is quite mysterious.

Appendix F.2, item 7
(typo) "depedent" should be "dependent".

Appendices H-J
Duplicating this information from section 6 seems unnecessary.  (Unlike
appendix G, which usefully brings together the information for each accessor.)
Received on Tuesday, 3 May 2005 14:11:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:05 UTC