W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2003

RE: DOM Level 3 Validation update

From: Curt Arnold <carnold@houston.rr.com>
Date: Wed, 05 Feb 2003 23:55:06 -0600
Message-ID: <3E41F8BA.6070203@houston.rr.com>
To: www-dom@w3.org

Are there any experimental implementations of DOM 3 Validation?  Are 
there any there any conformance tests in the pipeline?		

Comments:

continuousValidityChecking:

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

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.

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.

validateDocument:

How would warnings be issued?  There appears to be an interface name 
missing between "[DOM Level 3 Core]" and "interface"

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.

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

canSetAttributeNS:

Uses a qualifiedName parameter when similar methods use localName.

canSetAttributeNode:

"with respect to the validity check level" is unique to this method.

contentType:

The values for EMPTY_CONTENTTYPE etc are not defined.  An underscore 
between EMPTY_CONTENT_TYPE would be more readable.

isElementDefined and isElementDefinedNS:

Neither method depends on the target element.  Wouldn't these be better 
on NodeVAL?

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.

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.

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?
Received on Thursday, 6 February 2003 00:55:17 GMT

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