This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1293 - [DM] Editorial comments from XML Core WG
Summary: [DM] Editorial comments from XML Core WG
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Data Model 1.0 (show other bugs)
Version: Last Call drafts
Hardware: Macintosh All
: P2 minor
Target Milestone: ---
Assignee: Norman Walsh
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-03 14:11 UTC by Richard Tobin for XML Core WG
Modified: 2007-02-25 23:10 UTC (History)
0 users

See Also:


Attachments

Description Richard Tobin for XML Core WG 2005-05-03 14:11:00 UTC
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.)
Comment 1 Norman Walsh 2005-06-20 16:10:18 UTC
Thank you for your comments. Each of these items has been addressed as you
suggested, with the exception of the comment about appendixes H-J which I'm
inclined to leave for completeness.

Please let us know if you are unsatisfied by this resolution.
Comment 2 Richard Tobin for XML Core WG 2005-09-21 15:31:11 UTC
(In reply to comment #1)

The XML Core WG accepts your resolution of this comment.