Re: DOM Level 3 Validation update

Benjamin C. Chang wrote:

>
>>In the description of continuousValidityChecking, "the implementation if
>>free" should read "the implementation is free".
>>    
>>
>
>Changed.
>  
>

Satisified

>  
>
>>In addition several parts of that description are awkward.  "continuous
>>checking ... is enforced" might be better as "the validity of the
>>document is continuously enforced".  "If the document is invalid" seems
>>to have gotten separated from the sentence on setting the attribute.
>>    
>>
>
>Changed to read:
>"AN ATTRIBUTE SPECIFYING WHETHER THE VALIDITY
>OF THE DOCUMENT IS CONTINUOUSLY ENFORCED.  WHEN THE ATTRIBUTE IS SET TO
>TRUE, THE IMPLEMENTATION MAY RAISE CERTAIN EXCEPTIONS, DEPENDING ON THE
>SITUATION (SEE THE FOLLOWING).  THIS ATTRIBUTE IS FALSE BY DEFAULT."  A
>listing of the exceptions on setting
>follo
>

Satisified

>ws the description.
>
>  
>
>>getDefinedElementTypes:
>>
>>In the description of DocumentVAL.getDefinedElementTypes, "element's
>>namespace" appears repeatedly, but no clear definition of what element
>>might be involved.  There is an explicit namespaceURI parameter and
>>there might be a document element that has a namespace, but not quite
>>sure what element's namespace would be.
>>    
>>
>
>The description for getDefinedElements now reads:
>"RETURNS LIST OF ALL ELEMENT INFORMATION ITEM NAMES
>OF GLOBAL DECLARATION BELONGING TO THE SPECIFIED
>NAMES
>

Satisified

>PACE".
>
>  
>
>>validateDocument:
>>
>>How would warnings be issued?  There appears to be an interface name
>>missing between "[DOM Level 3 Core]" and "interface"
>>    
>>
>
>The method makes use of the passed-in error handler, as described
>in the DOM L3 CORE DOMConfiguration interface; warnings are
>handled through this exception handler.  There is a link to this
>interface now.
>  
>

A return value from the validation would be useful when the only 
interest was if the document was schema or DTD valid.  Without an 
explicit return value, it might be inferred that validation could be 
asynchronous.

>  
>
>>isNodeValid:
>>
>>    
>>
>>>Determines if the Node is valid relative to the grammar.
>>>It doesn't normalize before checking if the document is valid.
>>>      
>>>
>>"document" in the second sentence looks like a typo.
>>    
>>
>
>Corrected.
>
Satisified

>>allowedChildren:
>>
>> > Note that if no context of this element exists, then this is NULL; it
>>is an empty list if the element is not in the document tree.
>>
>>Not clear on the distinction between "no context" and "not in the
>>document tree".
>>    
>>
>
>They are the same; only "no context" is now referred to.
>  
>

Satisified

>>canSetAttributeNS:
>>
>>Uses a qualifiedName parameter when similar methods use localName.
>>    
>>
>
>This is modeled after setAttributeNS, so it will remain "qualifiedName".
>  
>
Satisified

>>canSetAttributeNode:
>>
>>"with respect to the validity check level" is unique to this method.
>>    
>>
>
>This phrase was deleted.
>  
>

Satisified

>  
>
>>contentType:
>>
>>The values for EMPTY_CONTENTTYPE etc are not defined.  An underscore
>>between EMPTY_CONTENT_TYPE would be more readable.
>>    
>>
>
>A definition group ContentTypeVAL with all the defined constants
>was added.  VAL_EMPTY_CONTENTTYPE is one of them; we decided
>not to add the extra underscore.
>

Satisified

>>isElementDefined and isElementDefinedNS:
>>
>>Neither method depends on the target element.  Wouldn't these be better
>>on NodeVAL?
>>    
>>
>
>No, an example of such a dependency would be the root element of a
>document.
>  
>

I guess they could depend on the target element for locally scoped 
element names.  However, I don't see an obvious reason these could not 
be implemented on Node.  Calling Document.isElementDefinedNS(ns, "foo") 
would be slightly different that  
doc.documentElement.isElementDefinedNS(ns, "foo") as the later would 
include elements defined in the scope of the document element.  

Alternatively, maybe a methods on the NameList's returned from 
allowableChildren et al would be better.  Would it be useful to 
determine if an element was defined in the grammar but not a potential 
child of the element?  Would isElementDefined[NS] return true if the 
name was defined as a locally scoped child element of some potential 
descendant of the current element?

I'm uneasy about this one.

>  
>
>>allowedNextSiblings, allowedPreviousSiblings:
>>
>>There aren't parallel methods that would determine if a character node
>>could be a previous or next sibling unless there is a special element
>>name for character nodes.
>>    
>>
>
>These could be done for character nodes via the canInsertBefore operation.
>  
>

Satisified

>>canDeleteData, canReplaceData, canInsertData:
>>
>>Would assume that this could throw the same exceptions as deleteData,
>>replaceData and insertData  if the offset or count parameters are out of
>>range.
>>    
>>
>
>Yes, they throw the same DOMException; this is listed now.
>  
>
Satisified

>>NameList:
>>
>>I could not locate a definition for NameList.  If it is defined in
>>another DOM spec, it should have a reference.  If not, then it is
>>underdefined.  How do you represent a namespace qualified name in a
>>namelist?
>>    
>>
>
>Yes, a link to DOM L3 has been added.
>

As previously mentioned, there is not yet a public definition of 
NameList and it is not possible to fully review or implement this spec 
without a provisional definition.

Received on Tuesday, 3 June 2003 00:24:53 UTC