Re: DOM Level 3 Validation update

Responses are below.

Thanks,
Ben

Curt Arnold wrote:

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

Yes, there will be two implementations written in Java.   Tests in the
W3C test framework will also be submitted.

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

Changed.

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

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

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

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

>
>
> canSetAttributeNS:
>
> Uses a qualifiedName parameter when similar methods use localName.

This is modeled after setAttributeNS, so it will remain "qualifiedName".

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

This phrase was deleted.

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

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

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

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

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

Received on Tuesday, 27 May 2003 17:59:41 UTC