- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 01 Apr 2004 14:11:08 -0500
- To: public-qt-comments@w3.org
- Message-id: <87u103ms37.fsf@nwalsh.com>
/ Henry Zongaro <zongaro@ca.ibm.com> was heard to say:
| Global
|
| Data model error messages should be numbered, as in other specifications
Fixed.
| Section 2.2.1
|
| The F&O namespace URI is out of date. It should be "
| http://www.w3.org/2003/11/xpath-functions".
Fixed.
| ------------------------------------------------------------------
|
| 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.
Fixed.
| ------------------------------------------------------------------
|
| Section 3
|
| In the last paragraph, "documents nodes" should be "document nodes".
Fixed.
| ------------------------------------------------------------------
|
| 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.
I disagree. The sections you are referring to are specifically about
construction from an Infoset and a PSVI, respectively. Those
constraints must hold in those sections.
| ------------------------------------------------------------------
|
| Section 3.3.3
|
| In the last example, "2003-01-16T16:30:00" should be
| "2003-01-02T16:30:00".
Fixed.
| ------------------------------------------------------------------
|
| Section 3.3.4
|
| For clarity, in the first bullet, after "timezone component is not the
| empty sequence", add "(timezone was specified)".
Fixed.
| ------------------------------------------------------------------
|
| Section 3.3.4
|
| For clarity, in the second bullet, after "timezone component is the empty
| sequence", add "(timezone was not specified)".
Fixed.
| ------------------------------------------------------------------
|
| Section 5
|
| In the third sentence of the second paragraph, "interface" should be
| changed to "information". The accessors do not provide a programming API.
Fixed.
| ------------------------------------------------------------------
|
| Section 5.2
|
| "namespace" is missing from the list of possible values that dm:node-kind
| can return.
Fixed.
| ------------------------------------------------------------------
|
| 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.
Fixed.
| ------------------------------------------------------------------
|
| 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.
Fixed.
| ------------------------------------------------------------------
|
| Section 6.2.4
|
| In the first sentence, "effected" should be "affected".
Fixed.
| ------------------------------------------------------------------
|
| 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.
I'm not sure that's necessary. It's mentioned at the end of the
section to indicate how all the unspecified properties are set.
| ------------------------------------------------------------------
|
| Section 6.2.4
|
| In the first bullet under "children", "string value is the the" should be
| "string value is the".
Fixed.
| ------------------------------------------------------------------
|
| Section 6.3.4
|
| In the first sentence, "effected" should be "affected".
Fixed.
| ------------------------------------------------------------------
|
| 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.
Fixed.
| ------------------------------------------------------------------
|
| 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.
I've tried to improve it, but there's no node-name property on
namespace nodes. Adding it in order to move this text to the
construction of that property doesn't seem like it would gain
anything.
| ------------------------------------------------------------------
|
| Section 6.5.3
|
| The title of this section should be "Construction from an Infoset" for
| consistency with earlier sections.
Fixed.
| ------------------------------------------------------------------
|
| 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).
Fixed.
| ------------------------------------------------------------------
|
| Section 6.6.3
|
| The title of this section should be "Construction from an Infoset" for
| consistency with earlier sections.
Fixed.
| ------------------------------------------------------------------
|
| 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.
Fixed.
| ------------------------------------------------------------------
|
| 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.
Fixed.
| ------------------------------------------------------------------
|
| 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.)
Fixed.
| ------------------------------------------------------------------
|
| Appendix B
|
| The reference to Infoset should be updated to point to Infoset, second
| edition.
Right.
| ------------------------------------------------------------------
|
| Appendix B
|
| The links and publications dates are incorrect for F&O and for
| Serialization.
Fixed.
| ------------------------------------------------------------------
|
| 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."
Fixed.
| ------------------------------------------------------------------
|
| Appendix D
I'll work on updating Appendix D before the next public draft.
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.
Received on Thursday, 1 April 2004 14:12:27 UTC