W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2004

[DM] IBM-DM-109: Data model editorial comments

From: Henry Zongaro <zongaro@ca.ibm.com>
Date: Tue, 17 Feb 2004 20:39:26 -0500
To: public-qt-comments@w3.org
Message-ID: <OFD54AECE0.E77DCB69-ON85256E3B.008217AF-85256E3E.00091A93@ca.ibm.com>

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Hello,

     Following are comments on Data Model that we believe to be editorial 
in nature.


------------------------------------------------------------------

Global

Data model error messages should be numbered, as in other specifications

------------------------------------------------------------------

Section 2.2.1

The F&O namespace URI is out of date. It should be "
http://www.w3.org/2003/11/xpath-functions".

------------------------------------------------------------------

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.

------------------------------------------------------------------

Section 3

In the last paragraph, "documents nodes" should be "document nodes".

------------------------------------------------------------------

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.

------------------------------------------------------------------

Section 3.3.3

In the last example, "2003-01-16T16:30:00" should be
"2003-01-02T16:30:00".

------------------------------------------------------------------

Section 3.3.4

For clarity, in the first bullet, after "timezone component is not the 
empty sequence", add "(timezone was specified)".

------------------------------------------------------------------

Section 3.3.4

For clarity, in the second bullet, after "timezone component is the empty 
sequence", add "(timezone was not specified)".

------------------------------------------------------------------

Section 5

In the third sentence of the second paragraph, "interface" should be 
changed to "information".  The accessors do not provide a programming API.

------------------------------------------------------------------

Section 5.2

"namespace" is missing from the list of possible values that dm:node-kind 
can return.

------------------------------------------------------------------

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.

------------------------------------------------------------------

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.

------------------------------------------------------------------

Section 6.2.4

In the first sentence, "effected" should be "affected".

------------------------------------------------------------------

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.

------------------------------------------------------------------

Section 6.2.4

In the first bullet under "children", "string value is the the" should be 
"string value is the".

------------------------------------------------------------------

Section 6.3.4

In the first sentence, "effected" should be "affected".

------------------------------------------------------------------

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.

------------------------------------------------------------------

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.

------------------------------------------------------------------

Section 6.5.3

The title of this section should be "Construction from an Infoset" for 
consistency with earlier sections.

------------------------------------------------------------------

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).

------------------------------------------------------------------

Section 6.6.3

The title of this section should be "Construction from an Infoset" for 
consistency with earlier sections.

------------------------------------------------------------------

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.

------------------------------------------------------------------

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.

------------------------------------------------------------------

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.)

------------------------------------------------------------------

Appendix B

The reference to Infoset should be updated to point to Infoset, second 
edition.

------------------------------------------------------------------

Appendix B

The links and publications dates are incorrect for F&O and for 
Serialization.

------------------------------------------------------------------

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."

------------------------------------------------------------------

Appendix D

In the example box for Attribute A1, the value of the dm:node-name
accessor is described as

  xs:QName("http://www.w3.org/2001/XMLSchema-instance",
           "xsi:schemaLocation")

"xsi:schemaLocation" should be "schemaLocation".


Similary, for Attribute A2, "xml:lang" should be "lang", for Attribute A6, 
"xlink:href" should be "href", for Element E5, "html:p" should be "p", for 
Attribute node A11, "xsi:nil" should be "nil".

------------------------------------------------------------------

Appendix D

In the example box for Comment C1, the value of the dm:typed-value 
accessor should be equal to the value of the dm:string-value accessor as 
an xs:string.

------------------------------------------------------------------

Appendix D

The orientation and size of the diagram at the end of this appendix make 
it difficult to read.  It might help to have to orient normally, with text 
in boxes running vertically, rather than horizontally.  Or, simply 
acknowledge that the compressed diagram isn't usable, and point to a 
larger image that is oriented normally, which people might not be able to 
print.

------------------------------------------------------------------

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Received on Tuesday, 17 February 2004 20:39:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:57 UTC