W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2003

Re: Last Call comments on DOM 3 Core Specification

From: Philippe Le Hegaret <plh@w3.org>
Date: 05 Aug 2003 14:44:19 -0400
To: Anjana Manian <Anjana.Manian@oracle.com>
Cc: WWW DOM <www-dom@w3.org>
Message-Id: <1060109058.5353.69.camel@jfouffa.w3.org>

On Wed, 2003-07-30 at 15:58, Anjana Manian wrote:
> 1. Section 1.2.4: (DOMObject):  
> "The DOMUserData type is used to store an application object."
> - DOMUserData in the above sentence needs to be changed to DOMObject

fixed.

> 2. Section 1.3.1: 
> "The DOM Level 3 Load and Save module provides a serialization mechanism
> and uses the 'normalize-characters' and
> 'check-character-normalization' to assure that text is fully-normalized. 
> 
> - 'normalize-characters' and 'Ƨheck-character-normalization' are used in
> the spec in the above sentence before defining them. Therefore it is not
> clear what is meant by them. Probably, it is required to rephrase this
> statement to say that these are configuration features and add a link to
> DOMConfiguration section.

fixed.

> 3. Interface DOMStringList: 
> "The DOMStringList interface provides the abstraction of an ordered
> collection of parallel pairs of name and namespace values..."
> 
> Isn't this a collection of DOMStrings ? If yes, the spec needs to be
> corrected. If not, it is not clear whether name or namespace should be
> returned by the method item(in index).

Issue tracked using
http://www.w3.org/2003/06/09-dom-core-issues/issues.html#arnold-4

> This interface could be moved to Validation spec as it is used only in
> Validation spec. 
>
> 4. Interface NameList:
> 
> This interface too can be moved to Validation spec as it is used only in
> Validation spec.

The purpose of having NameList in the Core draft is to allow its reuse
in an other DOM module, different from the DOM Validation one. It is the
same case for DOMTimeStamp, or some exception codes.

> 6. Interface Document:
>    
> - xmlStandalone: To be consistent with the other attributes, probably it
> should be added that  "This attribute is false when unspecified".
> 
> "ELEMENT_NODE: specified attribute nodes of the source element are
> adopted and the generated Attr nodes."
> - This sentence (in adoptNode) looks incomplete. Probably it should be
> rephrased.

removed "and the generated Attr nodes". Since the specified are adopted,
no Attr node is generated. Attr nodes may be generated if you have
default attributes, but this is reflected in the following sentence:
[[
Default attributes are discarded, though if the document being adopted
into defines default attributes for this element name, those are
assigned.
]]

> 7. Interface Text : 
> 
> "If the Text node is a direct child of the Document node, ..."
> -  Document can have only Element, ProcessingInstruction, Comment,
> DocumentType. So a text node can not be a direct child of the Document
> node.

correct. The sentence has been removed.

> 8. Interface DOMConfiguration:
> 
> "However when the feature 'LS' is defined in [DOM Level 3 Load and Save]
> is supported by DOM Implementation, the parameter 'resource-resolver'can
> also be used in DOMConfiguration.
> 
> - The parameter 'resource-resolver' is removed from DOM Level 3 Load and
> Save spec and therefore this sentence needs to be removed.

This inconsistency was also reported by Colin Paul Adams at:
http://lists.w3.org/Archives/Public/www-dom/2003JulSep/0015.html
I did not add this on the Core issues list since it is an error in the
LS draft.

[Other issues were added to the Core issues list]

Philippe
Received on Tuesday, 5 August 2003 14:44:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:57 GMT