Re: Comments on the DOM L3 Validation Specification

lmartin@ca.ibm.com wrote:

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

The DOM WG considered your comments and our responses are below.

Please let us know if you are satisfied (or not) with the resolutions.
If we do not hear back from you by June 4, we are assuming that you 
have no objections to our resolutions.

Thanks,
Ben Chang (on behalf of the DOM WG)


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

ACTION: AGREED; DONE

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.

ACTION: AGREED; DONE

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

ACTION: AGREED; DONE

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

ACTION: AGREED; DONE

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

ACTION: AGREED; DONE

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.

ACTION: AGREED; A LISTING OF EXCEPTIONS UPON SETTING WAS ADDED INSTEAD,
WITH VALIDATION_ERR NOTED AS A DOMEXCEPTION.

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

ACTION: AGREED; DONE


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

ACTION: AGREED; THE TERM "SCHEMA" IS NOW USED INSTEAD, WITH THE DEFINITION IN
THE DOM L3 GLOSSARY

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

ACTION: DECLINED; WHEN THERE IS A STANDARD MECHANISM TO BIND SCHEMAS TO 
DOCUMENTS, WE WILL SUPPORT IT, BUT SINCE THERE IS NONE TODAY, WE WILL NOT
BE THE ONES TO SPECIFY SUCH A STANDARD OR TO INDICATE HOW TO ATTACH SUCH
SCHEMAS TO DOCUMENTS.

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.

ACTION: AGREED; WE INTRODUCED ANOTHER TERM "VAL_INCOMPLETE" - "CHECK IF THE
NODE'S IMMEDIATE CHILDREN ARE THOSE EXPECTED BY THE CONTENT MODEL.  THIS 
NODE'S TRAILING REQUIRED CHILDREN COULD BE MISSING.  IT INCLUDES VAL_NS_WF." -
TO REPLACE THE PREVIOUS ONE FOR PARTIAL VALIDITY; AND "VAL_SCHEMA" TOUCHES
UPON SUBTREE VALIDITY.  

   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"

ACTION: AGREED; WE HAVE THE FOLLOWING VALIDATION TYPES: VAL_WF, VAL_NS_WF,
VAL_INCOMPLETE, VAL_SCHEMA; AND WE HAVE THE FOLLOWING VALIDATION STATES:
VAL_TRUE, VAL_FALSE, VAL_UNKNOWN.  SENTENCES PREVIOUSLY REFERRING TO PARTIAL
VALIDITY NOW READ LIKE "DETERMINES WHETHER THE ... WOULD MAKE THIS DOCUMENT
NOT COMPLIANT WITH THE VAL_COMPLETE VALIDITY TYPE."  IN ADDITION, THE 
AFFECTED VALIDATION METHODS HAVE BEEN CHANGED APPROPRIATELY TO RETURN THE
VALIDATION 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.

ACTION: AGREED; THIS NOW READS "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.

   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?

ACTION: AGREED; SEE 3A RESPONSE.

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.

ACTION: AGREED; DONE

   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?

ACTION: AGREED; THIS DESCRIPTION NOW READS "RETURNS LIST OF ALL ELEMENT
INFORMATION ITEM NAMES OF GLOBAL DECLARATION, BELONGING TO THE SPECIFIED
NAMESPACE."

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?

ACTION: AGREED; THIS NOW READS "ANY ATTEMPT TO MODIFY ANY PART OF THE 
DOCUMENT WHILE VALIDATING RESULTS IN IMPLEMENTATION-DEPENDENT BEHAVIOR.
IN ADDITION, THE VALIDATION OPERATION ITSELF CANNOT MODIFY THE DOCUMENT,
E.G., FOR DEFAULT ATTRIBUTES." 

   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.

ACTION: AGREED; THIS NOW READS "THIS METHOD MAKES USE OF THE PASSED-IN
ERROR HANDLER, AS DESCRIBED IN THE DOM LEVEL 3 CORE DOMCONFIGURATION 
INTERFACE, WITH ALL ERRORS BEING SEVERITY_ERROR AS DEFINED IN THE 
DOMERROR INTERFACE".

   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?

ACTION: AGREED; THE VALIDATION METHODS NOW ALL RETURN A VALIDATION STATE
CONSTANT.  AN APPENDIX DESCRIBING THE VALIDATION OUTCOMES HAS ALSO BEEN 
ADDED.

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?

ACTION: AGREED; THE BEGINNING SENTENCE NOW READS "DETERMINES IF THE NODE
IS VALID RELATIVE TO THE VALIDATION TYPE SPECIFIED IN VALTYPE..."

   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.

ACTION: AGREED; SEE 5C RESPONSE.

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

ACTION: AGREED; DONE 

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?

ACTION: AGREED; THIS NOW READS "A DOMSTRINGLIST, AS DESCRIBED IN DOM LEVEL 3
CORE, OF DISTINCT VALUES FOR AN ATTRIBUTE OR AN ELEMENT DECLARATION OR 
NULL IF UNSPECIFIED.  IF THE SCHEMA IS AN XML SCHEMA, THIS IS THE CANONICAL
LEXICAL REPRESENTATION OF THE ENUMERATION COMPONENTS."   ENUMERATION IS 
AS DEFINED AS IN DTD SO NO MENTION WILL BE MADE.

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

ACTION: DECLINED; WE WANTED TO AVOID DIAMOND INHERITANCE.

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?

ACTION: DECLINED; ISNODEVALID, NOW RENAMED TO NODEVALIDITY, DOES NOT
THROW AN EXCEPTION NOW BUT RETURNS A VALIDATION STATE CONSTANT.  THIS IS
TRUE FOR ALL THE CAN* METHODS; IF NO SCHEMA IS FOUND, VAL_TRUE IS RETURNED.

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?

ACTION: AGREED; A SECTION ON WILDCARDS WAS ADDED, ALONG WITH THE APPROPRIATE
CHANGES IN THE ATTRIBUTE DESCRIPTIONS.

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?

ACTION: AGREED; THIS NOW READS "DETERMINES IF NAME IS DEFINED IN THE SCHEMA.
THIS ONLY APPLIES TO GLOBAL DECLARATIONS.  THIS METHOD IS FOR NON-NAMESPACE
AWARE SCHEMAS."  GLOBAL DECLARATIONS WAS ADDED TO THE DOM L3 GLOSSARY.

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?

ACTION: AGREED; THIS NOW READS "DETERMINES IF NAME IN THIS NAMESPACE IS 
DEFINED IN THE CURRENT CONTEXT.  THUS NOT ONLY DOES THIS APPLY TO GLOBAL
DECLARATIONS, BUT DEPENDING ON THE CONTENT, THIS MAY ALSO APPLY TO LOCAL
DEFINITIONS.  THIS METHODS IS FOR NAMESPACE-AWARE SCHEMAS."

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

ACTION: AGREED; RENAMED VAL_SIMPLE_CONTENTTYPE, THE PREVIOUS CONSTANT'S 
DEFINITION NOW READS "THE CONTENT MODEL CONTAINS CHARACTER INFORMATION ITEMS.
IF THE SCHEMA IS AN XML SCHEMA, THIS CORRESPONDS TO THE SIMPLE TYPE DEFINITION."

   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>

ACTION: AGREED; RENAMED VAL_ANY_CONTENTTYPE, THE PREVIOUS CONSTANT'S
DEFINITION NOW READS "THE CONTENT MODEL CONTAINS UNORDERED CHILD INFORMATION
ITEM(S), I.E., ELEMENT, PI, UNEXPANDED ENTITY REFERENCE, CHARACTER, AND
COMMENT INFORMATION ITEMS AS DEFINED IN THE XML INFORMATION SET.  IF THE 
SCHEMA IS A DTD, THIS CORRESPONDS TO THE ANY CONTENT MODEL."  RENAMED
VAL_MIXED_CONTENTTYPE, THE PREVIOUS CONSTANT'S DEFINITION NOW READS
"THE CONTENT MODEL CONTAINS A SEQUENCE OF ORDERED ELEMENT INFORMATION ITEMS
OPTIONALLY INTERSPERSED WITH CHARACTER DATA.  IF THE SCHEMA IS AN XML SCHEMA,
THIS CORRESPONDS TO THE MIXED CONTENT TYPE."

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

ACTION: AGREED; THIS NOW READS "DETERMINES IF CHARACTER DATA IS ONLY 
WHITESPACE" AND THE METHOD RETURNS A VALIDATION STATE CONSTANT.

Received on Friday, 23 May 2003 13:58:15 UTC