L3 Core Last call issue responses

My responses to issues that I raised, 

arnold-1: NameList: contains and containsNS - satisified

arnold-2: attribute name case:  Satisified pending HTML errata

arnold-3: hasFeature and Core 1.0: satisifed

arnold-4: ordered collection - satisifed

arnold-5: getName vs getLocalName

The description of the resolution in the last call list is a cut and 
paste of arnold-4.  It appears the intended resolution was to not 
specify the interpretation of name within the interface but require 
methods that return the interface to specify whether name was qualified 
or local.

arnold-6: exceptions in NameList - satisified

arnold-7: DOMImplementationSource: satisified

arnold-8: actual encoding? - satisified

arnold-9: config or configuration - satisified

arnold-10: documentURI and valid URIs - satisified

arnold-11: recognized XML encoding - satisified

arnold-12: Requirements of standalone: satisified

arnold-13: adoptNode and importNode - satisified

arnold-14: adoptNode return value - satisified

arnold-15: Attributes and rename node - satisified

arnold-16: Position comparison

Not satisified and I will elaborate in another message.  There were 
multiple objections only one was addressed in the response.

arnold-17: getFeature and hasFeature - satisified

arnold-18a: isWhitespaceInElementContent() or isWhitespaceInElementContent

Satisified with the change to a read-only attribute.  Still believe the 
conditions that a value of true can be expected could be clarified.


    The text node is determined to contain whitespace in element content
    during the load of the document or if validation occurs while using

Determining if a text node is element content whitespace requires 
validation in any case, not just when normalizing.  Maybe:

    The text node is determined to contain whitespace in element content
    if validation occurs during the load of the document or during a
    call to Document.normalizeDocument().


    Returns whether this text node contains whitespace in element content,

If validation is enabled and an error handler is registered that ignores 
validation errors, you could have a text node where it is known to be in 
element content which contains both whitespace and some non-whitespace 
characters.  In this case, some of the characters would be element 
content whitespace per Infoset and others would not be.  "contains" 
would imply that the value should be true as only as at least one 
whitespace character appears.  "contains only" might be preferrable.

I believe this attribute will be subject to abuse since there is not a 
simple way to determine if a text node contains only whitespace 
independently of validation.  Adding CharacterData.isWhitespace readonly 
attribute would provide a simple means for determining if a character 
data node was exclusively whitespace irregardless of its context or 
whether validation was enabled.

arnold-18: isId() or isId

Satisified with changing isId to an attribute.  If the setIdAttribute* 
are needed for performance reasons, I would still like to see isId to be 
read-write and have the setIdAttribute* convienience functions to be 
defined in terms of setting isId.

arnold-19: DOMError clone: Satisified

arnold-20: User data and event handling: Satisified

arnold-21, arnold-22, arnold-23: TypeInfo related issues

Will need to be review and follow up in another message.

arnold-24: handleErrors

Satisified, but there is a minor typo ("he" instead of "The") in the 
return value description for DOMErrorHandler.handleError in the working 
group draft.

arnold-25: byte and character offsets: Satisified.

Received on Monday, 27 October 2003 17:49:52 UTC