Comments on the DOM L3 Validation Specification

Dear Colleagues:

The XML Schema WG congratulates the DOM  WG on the publication of the Last
Call draft of DOM L3 Validation last October.
We apologize profusely for missing the deadline for comments of this draft.


We have now reviewed the revised working draft of Feb. 5 2003 [1] that you
referred us to, and have some comments/suggestions/questions below.   The
XML Schema WG is still discussing one further comment, which we may send on
in subsequent mail.

We hope our comments are helpful.   Please let us know if any further
clarification is required, or if further discussion would be beneficial.
Thank you.
Lisa Martin (on behalf of the XML Schema WG)

[1]  http://www.w3.org/TR/2003/WD-DOM-Level-3-Val-20030205/


A. Editorial comments:
---------------------------------
1. Section 1.1 Overview, 2nd paragraph,
   change " ... a XML document..." to "...an XML document..."

2. Section 1.1 Overview, 2nd paragraph
   change "...lists of defined symbols of a given type." to "...lists of
   defined symbols of a given kind...",   to avoid overloading the term
   "type" in a schema context.

3. Section 1.2, ExceptionVAL,
   change "...may throw a ExceptionVAL..." to  "...may throw an
   ExceptionVAL..."

4. Section 1.3, Document Editing Interfaces, 1st paragraph,
   change "CharacterEditVAL" to "CharacterDataEditVAL" and add a link to
   the relevant section.

5. Section 1.3, Document Editing Interfaces, description of
continuousValidityChecking,
   change "...the implementation if free..." to "...the implementation is
   free..."

6.  Section 1.3, Document Editing Interfaces, description of
continuousValidityChecking,
   This section contains references to "VALIDATION_ERR".   We suggest you
   provide a link to the section in DOM L3 Core that defines this value.

7. Section 1.3, Document Editing Interfaces, Interface NodeEditVAL, 1st
paragraph,
   change "... Node interfaces..." to "...Node interface"


B. Substantive Comments/Suggestions/Questions
--------------------------------------------------------------------------
1. There are many references to "grammar" in the specification, but
"grammar" is never defined.    Also, we feel that this specification should
also indicate how grammars are bound to the document , and whether multiple
types of grammars can be bound to the document.   If this is covered by
other DOM L3 specifications, we feel there should be a pointer from the
Validation specification to the relevant sections of the other
specification(s).

2. "partial validity" and "strict validity"

   a.  Partial validity is defined in DOM L3 Core as follows:

   "A node in a DOM tree is partially valid if it is well formed (this part
   is for comments and processing instructions) and its immediate children
   are those expected by the content model. The node may be missing
   trailing required children yet still be considered partially valid."

   This does not indicate whether recursively, the children of such a node
   need to be valid or partially valid (or not), for the parent to be
   partially valid, and it probably ought to.

   b.  We would prefer that alternative terminology be used for "partial
   validity" and "strict validity", as these terms may cause confusion for
   XML Schema users.   For example, the XML Schema PSVI contains a
   [validation attempted] property whose value may be "partial" and this is
   not the same as "partial validity" as is currently defined in DOM L3;
   similiarly, XML Schema contains a notion of "strict assessment", and we
   don't _believe_ this is the same as DOM L3's "strict validity"  (but,
   see question 2c below).

   As an alternative, we suggest that the spec defines that while editing a
   document, the document may be in one of the following states:
      "incomplete" (loosely, a replacement for partial validity.  Comment
      2a still applies)
      "valid"
      "invalid"
      "unknown"   (note that XML Schema assessment may result in an element
      information item's [validity] to be unknown)

   References to partial validity may then be removed.   For example, the
   description of  DocumentEditVAL.continousValidity could be changed from:
      "When set to true, the implementation is free to raise the
      VALIDATION_ERR exception on DOM operations that would make the
      document invalid with respect to partial validity"
   to:
      "When set to true, the implementation is free to raise the
      VALIDATION_ERR exception on DOM operations that would move the
      document into an invalid state"

   If this suggestion is not accepted, then we have the following comments:

   c. We were not able to find a definition of "strict validity" in this
   specification, nor in the Glossary of DOM L3 Core, and believe it ought
   to be defined.

   d. The specification does not indicate what it means for a document to
   be invalid with respect to partial validity.



3. Section 1.3 Interface DocumentEditVAL, Description of
continuousValidityChecking
   a. The description includes the sentence "Setting this to true will
   result in an exception being thrown, i.e., VALIDATION_ERR, for documents
   that are invalid at the time of the call."   This text should probably
   be clarified to indicate what "the call" is.

   b. The text states "If the document is invalid, then this attribute will
   remain false".   Does this mean that as soon as the document becomes
   invalid, this attribute becomes false and stays false, or only as long
   as the document is invalid?

4. Section 1.3 Interface DocumentEditVAL, Description of
getDefinedElementTypes
   a. We would prefer that the method be named "getDefinedElements" since
   XML Schema distinguishes between element declarations and types.

   b. The description says "Returns list of all element node names
   belonging to the element's namespace".   Which element is being referred
   to?   Shouldn't this text reference instead the namespaceURI which is a
   parameter to the method?    Also, is this method intended to return a
   list of names of elements with declarations in the "grammar"/schema?
   If so, the description should probably be more precise.      Also, will
   this list include names from both global and local element declarations
   in XML Schema?

5. Section 1.3 Interface DocumentEditVAL, Description of validateDocument
   a. The text states "If the document is mutated during validation, a
   warning will be issued.  In addition, the validation cannot modify the
   document, e.g. for default attributes."   What is meant by mutated in
   this text?   Doesn't mutate mean "change/modify"?   If so, what is the
   purpose of the 2nd sentence then?

   b. The description says "This method makes use of the passed-in error
   handler ...".     We assume this means, if the document is not valid,
   then an error is detected.     Is the severity of such a problem
   SEVERITY_ERROR?   This ought to be clarified.    Also, it is not clear
   how this error-handler is "passed-in".   Perhaps a link to the relevant
   text in DOM L3 Core would be appropriate.

   c.  If the document is being assessed with respect to a schema (XML
   Schema), and if the [validity] as defined in the PSVI is unKnown, how is
   that communicated back to the application?   Also, if the [validation
   atttempted] property in the PSVI is "none" or "partial", how is this
   communicated back to the application?   Generally, how is the variety of
   XML Schema assessment outcomes dealt with?

6. Section 1.3, Interface NodeEditVAL, method isNodeValid()
   a. The definition states "Determines if the Node is valid relative to
   the grammar".   What does this mean?   Is this intended check for local
   validity as is defined in XML Schema?

   b.  Similiar to comment 5(c), how are the variety of XML Schema
   assessment outcomes dealt with?   For example, if the validity of an
   element was not assessed, perhaps because no element declaration or type
   could be found for it,  how is this communicated to the application?
   And, how can the parameters "deep" and "wfValidityCheckLevel" be used to
   inquire about schema validity?   An explicit discussion of how these
   parameters relate to the values in the PSVI would be helpful.

7.  Section 1.3, Interface NodeEditVAL, method canAppendChild
   Shouldn't   "Determines whether the Node.replaceChild operation ..."
   be "Determines whether the Node.appendChild operation..."?

8. Section 1.3, Interface NodeEditVAL, enumeratedValues attribute
   This is described as a list of "distinct values" for an attribute or
   element declaration.   For XML Schema, is this the set of strings which
   are the canonical representations of the values in the enumeration
   component of the attribute or element's type definition?    And, can you
   clarify what this attribute is if the grammar is a DTD?

9.   Section 1.3, Interface NodeEditVAL
   Should this interface extend the Node interface?   (similiar to the way
   in which the RangeVAL interface extends Range)?

10. Section 1.3, Interface NodeEditVAL, canAppendChild, etc. methods
   These methods do not throw any exceptions, but "isNodeValid" will throw
   an exception if there is no grammar.   Should the canX methods also
   throw an exception if there is no grammar?


11. Section 1.3, Interface ElementEditVAL:  allowedAttributes,
allowedChildren
   allowedAttributes is a Namelist of possible attributes which can appear
   with this type of element.    What if the type of the element specifies
   an attribute wildcard?   What does this list contain?  Similiarly, the
   allowedChildren attribute is a NameList of possible elements that can
   appear as children of this type of element.   What if the content of the
   type of the element permits wildcards?

12. Section 1.3, Interface ElementEditVAL, isElementDefined
   "Determines if name is defined in the grammar".    If "name" has a local
   declaration in a schema (XML Schema), does this return true?   Or does
   this only apply to globally defined elements?

13. Section 1.3, Interface ElementEditVAL, isElementDefinedNS
   What does "current context" mean in "Determines if name in this
   namespace is defined in the current context"?   As with comment 12, if
   the element is declared local to some complex type, does this method
   return true?      Such a declaration may collide with a top-level
   element declaration in the same namespace.   Is this an issue?

14. Section 1.3, Interface ElementEditVAL, contentType
    a. SIMPLE_CONTENTTYPE is defined as:  "content type of an element which
   contains character data with attributes".    Shouldn't this say
   "possibly with attributes"?

   b. ANY_CONTENTTYPE is defined as:  "content type of an element which can
   contain zero or more child elements as well as character data" and
   MIXED_CONTENTTYPE is defined as: "content type of an element which
   contains character data optionally interspersed with child elements".
   What is the content type for the following?
      <xsd:complexType mixed="true">
        <xsd:sequence>
         <xsd:any minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
       </xsd:complexType>
   and
      <xsd:complexType mixed="true">
        <xsd:sequence minOccurs="0" maxOccurs="unbounded">
         <xsd:any/>
        </xsd:sequence>
       </xsd:complexType>

15. Section 1.3, Interface CharacterDataEditVAL, isWhiteSpaceOnly
   Should "true if content only whitespace; false for non-whitespace" read
   "true if contains only whitespace;  otherwise false" ?

Received on Friday, 21 February 2003 17:23:45 UTC