This document contains a list of issues regarding the DOM Level 3 Validation specification Last Call period. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives) before November 27, 2002.
As of 2 July 2003, this issues list is now closed.
| Id: Title | State | Type | Ack. |
|---|---|---|---|
| litani1 : Document-editing interfaces description | agreed | editorial | Agreement |
| litani2 : Active grammar references | agreed | editorial | Agreement |
| litani3 : Missing contentType constants | agreed | editorial | Agreement |
| litani4 : wfValidityCheckLevel parameter should be added | agreed | proposal | Agreement |
| litani5 : Add canWrap() convenience method | agreed | proposal | Agreement |
| litani6 : Add getNextSiblings/getPreviousSiblings convenience methods | agreed | proposal | Agreement |
| litani7 : Add getAlternativeElements method | agreed | proposal | Agreement |
| litani8 : Add getRequiredAttributes method | agreed | proposal | Agreement |
| litani9 : Add methods to retrieve enumerated and default values | agreed | proposal | Agreement |
| litani10 : Change NodeList return types to list of QNames | agreed | proposal | Agreement |
| litani11 : Remove getParentElements method | declined | proposal | Agreement |
| ausbrooks1 : More stringent validation for some XML dialects | declined | proposal | Agreement |
| curt1 : NO_GRAMMAR_AVAILABLE | agreed | editorial | Agreement |
| curt2 : contentType | agreed | proposal | Agreement |
| curt3 : allowedChildren | agreed | proposal | No reply from reviewer |
| curt4 : requiredAttributes | declined | proposal | Agreement |
| curt5 : NameList | subsumed [curt22] | proposal | |
| curt6 : External grammars | agreed | proposal | Agreement |
| curt7 : Separation of Validation features | declined | proposal | Agreement |
| curt8 : Exceptions on setting continousValidityChecking | agreed | proposal | Agreement |
| curt9 : RangeVAL | declined | proposal | Agreement |
| curt10 : VAL-DOC | agreed | proposal | Agreement |
| curt11 : continuousValidityChecking typo | agreed | editorial | Agreement |
| curt12 : continuousValidityChecking description | agreed | editorial | Agreement |
| curt13 : getDefinedElements description | agreed | editorial | Agreement |
| curt14 : validateDocument description | agreed | editorial | No reply from reviewer |
| curt15 : isNodeValid typo | agreed | editorial | Agreement |
| curt16 : allowedChildren description | agreed | editorial | Agreement |
| curt17 : canSetAttributeNS qualifiedName parameter | declined | editorial | Agreement |
| curt18 : canSetAttributeNode description | agreed | editorial | Agreement |
| curt19 : contentType values | agreed | proposal | Agreement |
| curt20 : isElementDefined and isElementDefinedNS | declined | proposal | No reply from reviewer |
| curt21 : canDeleteData, canReplaceData, canInsertData exceptions | agreed | proposal | Agreement |
| curt22 : NameList link | moved | editorial | No reply from reviewer |
| lmartin1 : Editorial comments | agreed | editorial | Agreement |
| lmartin2 : Grammar definition | agreed | proposal | Agreement |
| lmartin3 : Binding schemas to documents | declined | proposal | Agreement |
| lmartin4 : Partial validity rewrite | agreed | proposal | Agreement |
| lmartin5 : Alternative term/definition for partial validity | agreed | proposal | Agreement |
| lmartin6 : continuousValidityChecking description clarification | agreed | editorial | Agreement |
| lmartin7 : continuousValidityChecking further clarification | agreed | editorial | Agreement |
| lmartin8 : Rename getDefinedElementTypes | agreed | proposal | Agreement |
| lmartin9 : getDefinedElements description | agreed | editorial | Agreement |
| lmartin10 : validateDocument description | agreed | editorial | Agreement |
| lmartin11 : Description of error handler for validateDocument | agreed | editorial | Agreement |
| lmartin12 : Different validation outcomes | declined | proposal | Agreement |
| lmartin13 : isNodeValid definition | agreed | editorial | Agreement |
| lmartin14 : Different outcomes | agreed | proposal | Agreement |
| lmartin15 : canAppendChild description typo | agreed | editorial | Agreement |
| lmartin16 : enumeratedValues description clarification | agreed | editorial | Agreement |
| lmartin17 : NodeEditVAL interface to extend Node? | declined | proposal | Agreement |
| lmartin18 : can* methods to throw exception if no grammar | agreed | proposal | Agreement |
| lmartin19 : Discussion of wildcards for allowed* methods | agreed | proposal | Agreement |
| lmartin20 : isElementDefined description clarification | agreed | editorial | Agreement |
| lmartin21 : isElementDefinedNS description clarification | agreed | editorial | Agreement |
| lmartin22 : SIMPLE_CONTENTTYPE description clarification | agreed | editorial | Agreement |
| lmartin23 : ANY_CONTENTTYPE description clarification | agreed | editorial | Agreement |
| lmartin24 : isWhiteSpaceOnly description clarification | agreed | editorial | Agreement |
Change 1.3 document-editing interfaces descriptions, which current read "This interface extends the _Element_ interface with additional methods for guided document editing. An object implementing this interface must also implement _NodeEditVAL_ interface."
The descriptions will read: "This interface extends the _NodeEditVAL_ interface with additional methods for guided document editing. An object implementing this interface must also implement _Element_ interface."
Changes were made in the specification per the email.
Remove references to active grammar since no definition exists.
In some methods like isElementDefinedNS, "currently active grammar" should be replaced by "current context".
Changes were made in the specification per the email.
SIMPLE_TYPE as well as definition of content type constants are missing.
These constants will be added.
Changes were made in the specification per the email.
This parameter should be added to methods like canAppendChild to allow users to specify at what level validation should happen.
It was decided to instead modify the definition of partial validity by removing "this part is for comments and processing instructions", and add to the description of all can* methods on NodeEditVal to reference the link to partial validity in the glossary.
Changes to be made in the specification per the email.
Instead of using expensive operations to a) get all children of "x"; b) get all possible parents of "y"; c) check if "b" is present in both sets, a convenience method should be added.
A convenience method canSurroundContents() will be added as an extension of Range since it makes more sense there.
Changes to be made in the specification per the email.
No easy way to fix an invalid document if an user starts from it. To fix it, an user might need to remove all children of the root first and then try to add those again using can* methods.
It was decided that these be attributes called allowedNextSiblings and allowedPreviousSiblings on the ElementEditVal interface instead, with type NameList.
Changes to be made in the specification per the email.
Because of substitution groups, an operation that will return a list of alternative elements is needed.
A method getAlternativeElements that takes reference child as a parameter will return a list of alternative elements; this will be considered as another method to be added to the proposed Range extension.
Users would usually like to add required attributes to a newly created element to make it valid.
An attribute requiredAttributes of type NameList will be added to the ElementEditVal interface. These are a NameList of required Attr nodes that must appear with this type of element.
Changes to be made in the specification per the email.
Since the AS model is gone, no methods exist to retrieve enumerated and default values.
Attributes defaultValue of type DOMString and enumeratedValues of type DOMStringList were added to the NodeEditVal interface.
It would be more efficient to return a list of QNames than a NodeList for certain operations, and let the user created only the nodes that are needed.
Attributes to describe allowed children/parents/attributes of type NameList will be added to the ElementEditVal interface. The getDefinedElementTypes method was moved to the DocumentEditVal interface, with a return type of NameList.
It is not considered useful and is not performant.
It is useful when the element has no parent.
To accommodate their extensions, they proposed adding a new CheckTypeVAL constant, e.g., "MATHML_STRICT_VALIDITY_CHECK", so that validation would include these non-codifiable restrictions. In addition, a feature string such as "MATHML-VAL-DOC" would be needed.
Their proposal was declined; documentation was added to indicate that if groups wanted such extensions, they could do so on their own.
NO_GRAMMAR_AVAILABLE appears to be the only exception code in the DOM universe that does not end in _ERR.
This was changed to NO_SCHEMA_AVAILABLE_ERR.
ElementEditVAL.contentType is currently a method, though it seems like it would be better as a read-only attribute.
This was made a read-only attribute.
ElementEditVal.allowedChildren isn't all that useful. What you really would want is a list of all the element names (and maybe #text if character content would be allowed) that could appear as the initial child of the element. If you had a content model like (j, (a|b|c|d|e|f|g|h|i|k|m|n|o|p)) you would want to guide the user to start a <j> element. Once you had that inserted, you could use NodeEditVal.allowableNextSiblings to guide through the rest of the content model.
The proposed name allowedFirstChildElements seems inconsistent with name allowedChildren. Other than that, I am satisified with the resolution.
allowedChildren is very flexible; subsequent operations would achieve your desired results. Your suggestion of having a convenience attribute (the allowed* are all attributes) allowedFirstChildElements was incorporated.
The name has been changed to match
allowedChildren: the method is now called
allowedFirstChildren.
ElementEditVal.allowedAttributes is good, but it would also be helpful for have an ElementEditVal.requiredAttributes and maybe an ElementEditVal.fixedAttributes.
requiredAttributes was already there; you must have missed it. We decided against adding a fixedAttributes attribute for now.
It would be useful if DocumentEditVal had a method that took a value from a NameList from allowedChildren, allowedNextSiblings, et al and created the corresponding node. The format of the NameList entries is not described, but without such a method, it would be necessary to parse the entry into the namespace and local name and then call the corresponding CreateElement or CreateElementNS. Something like: Node CreateNode(string nameListName) where if nameListName was '@foo', you'd get an attribute, if nameListName was #text, you'd get a CharacterDataNode and if 'transform:http://www.w3.org/1999/XSL/Transform", an XSLT transform element and if "foo" a DOM L1 element. That would suggest that allowedAttributes should return the attribute values starting with a "@". You'd also need to specify how you'd represent namespace qualified attributes.
The current public working draft of L3 Core does not define NameList. I assume that it is defined in the current working group draft. If NameList has a provision to creation of nodes from a name entry, then I would be satisified with the resolution.
If you take a look at the DOM L3 CORE NameList description, these are not needed.
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.
There does not seem to be any provision for the caller to specify a specific grammar for validation. Validation depends on the document containing a document type declaration, a xsi:schemaLocation or equivalent. A grammar attribute of type Node on DocumentEditVAL could be used to specify the external grammar (also potentially determine default grammars located by xsi:schemaLocation attributes, though that might be add more complication than it is valuable). DTD's could be associated by loading a template document and setting DocumentEditVAL.grammer to the DocumentType node of the template document. Schemas could be associated by setting grammer to an Element or Document node containing a single schema. Schema collections could be represented by a DocumentFragment containing multiple xs:schema elements. validateDocument() would also need a grammar parameter. The working draft does not discuss the behavior if a schema location hint is modified or removed. Would removing a xsi:schemaLocation attribute on the document element allow you to change the document at will?
I believe that validation against an external schema (that is, one not specified my xsi:schemaLocation or a document type declaration) is a very significant use case for validation and one for which there is no mechanism to accomplish by my reading of the L3 drafts.
Since the effect of modifying or removing the schema location information (for example, adding an xsi:schemaLocation attribute) is implementation dependent, there is no mechanism after the document is loaded to modify the schema location.
However, this suggests that load/save might be the appropriate part of L3 to address the issue. One possibly mechanism would be to extend DOMBuilder.createDOMBuilder to have a schemaLocation or schemaNode parameter that could specify the URL (or Node) for the schema document to be used during document parsing.
I'll concede that the validation draft may not be the place that needs to address this use case, but I would strongly suggest that the use case be addressed by one of the specs. I would be satisified with delegating this issue to another subspec as a resolution, however I would not be satisified if there was no mechanism in L3 to address this use case.
We decided to not add the requested functionality. There are different ways to determine what schema is associated with the document, e.g., DOM L3 CORE schemaTypeInfo, but since there is no standard mechanism to bind schemas to documents, we will not be the ones to specify such a standard or to indicate how to attach such schemas to documents. If schema location were modified or removed, behavior would be implementation dependent.
DOMConfiguration.setParameter("schema-location",
...) appears to be intended to support the use
case.
The Validation draft supports three major features: validation, guiding document editing by enumerating allowable > changes and inhibiting DOM mutations that would (possibly temporarily) invalidate the document. However, these three features vary widely in their maturity. Many implementations could support an on-demand validation feature, but very few could currently support editing support and mutation inhibition. However, the working draft does not allow implementations to support anything less than all three features. I would suggest that distinct features names and interfaces be defined so that an implementation that only supported on-demand validation could partially implement the spec.
We decided to not divide into 3 feature areas as you suggest, since we thought the current implementation was fine as-is. Implementors who wish to implement a subset may be free to do so, but we think the entire set of functionality is straightforward to implement and should not take that much time to do so.
Looking at the DocumentEditVAL interface, the only method that is Editing related in getDefinedElementTypes(). I previously noted that the description is confusing, but my guess is that it is equally applicable to all nodes and could be moved to the NodeEditVAL interface. Validation, both on-demand and continuous could be supported by a single DocumentVAL interface, something like (including suggestions from the previous note on external grammars)... Code snippet raises NOT_SUPPORTED_ERR, NO_GRAMMAR_AVAILABLE_ERR, and VALIDATION_ERR. The remaining interfaces would then have no Validity features and should probably be renamed from NodeEditVAL to NodeEdit, etc.
See our previous response about the proposed feature division. Doc was added for the various exceptions on setting of the continuousValidityChecking attribute.
RangeVAL is unusally named since it is the only interface that does not end in EditVAL. It does appear to be exclusively editing, so I'd rename it RangeEdit. But if everything else in this message is rejected, it would be good to rename it as RangeEditVAL for consistency.
We decided to omit the RangeEditVAL interface for now since the two Validation implementations currently being done were not going to implement it and there weren't many "customers" asking for these.
I assume the "VAL-DOC" feature name is a hold-over from earlier drafts. It seems fairly random in the context of the current draft. Separation of Validation from Editing features would require a distinct feature name (such as "VAL-EDIT") to identify implementations that provide editing support.
Yes, this was changed to "Validation".
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.
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".
How would warnings be issued? There appears to be an interface name missing between "[DOM Level 3 Core]" and "interface"
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.
"Passed-in error handler" suggests that an instance of DOMErrorHandler is a parameter on the call to validateDocument. If it were then there would be no need to reference the definition of DOMConfiguration.
If the intention to cast the document to DOMConfiguration and call the setParameter("error-handler", errorHandler), then you would need to define what would occur if setParameter("schema-location",...) was called after loading but before calling validateDocument. Changing the schema locations after document construction could be so disruptive that you may want to prevent it and use importNode when you want to recreate a document with a different schema. If DOMConfiguration was then only used as part of document loading, it might be moved from Core to Load/Save.
My current preference is to define validateDocument as:
boolean validateDocument(DOMErrorHandler errorHandler)
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.
The "passed-in" adjective was deleted. A config attribute of type DOMConfiguration has been added to the DocumentEditVAL interface to allow the setting of the error handler. The validateDocument method returns a validation state constant.
"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.
"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.
Uses a qualifiedName parameter when similar methods use localName.
This is modeled after setAttributeNS, so it will remain "qualifiedName".
"with respect to the validity check level" is unique to this method.
This phrase was deleted
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.
Neither method depends on the target element. Wouldn't these be better on NodeVAL?
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.
Adding boolean contains(DOMString name); boolean containsNS(DOMString namespace, DOMString localName); might allow the elimination of ElementEditVal.isElementDefined[NS]
No, an example of such a dependency would be the root element of a document.
We have decided to keep isElementDefined[NS], as implementations could be more efficient if left as currently defined and there are no compelling reasons to eliminate or move these methods. The suggestion about adding contains[NS] to DOM L3 Core will be considered.
Neither method depends on the target element. Wouldn't these be better on NodeVAL?
Yes, they throw the same DOMException; this is listed now.
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?
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.
Yes, a link to DOM L3 has been added.
Your request to consider the addition of contains and containsNS has accepted as a DOM Level 3 Core Last Call issue.
Section 1.1 Overview, 2nd paragraph, change " ... a XML document..." to "...an XML document...";
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;
Section 1.2, ExceptionVAL, change "...may throw a ExceptionVAL..." to "...may throw an ExceptionVAL...";
Section 1.3, Document Editing Interfaces, 1st paragraph, change "CharacterEditVAL" to "CharacterDataEditVAL" and add a link to the relevant section;
Section 1.3, Document Editing Interfaces, description of continuousValidityChecking, change "...the implementation if free..." to "...the implementation is free...";
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;
Section 1.3, Document Editing Interfaces, Interface NodeEditVAL, 1st paragraph, change "... Node interfaces..." to "...Node interface"
Corrected. For 6), a listing of exceptions upon setting was added instead, with VALIDATION_ERR noted as a DOMException.
There are many references to "grammar" in the specification, but "grammar" is never defined.
The term "schema" is now used instead, with the definition in the DOM L3 glossary.
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).
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.
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.
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 sub-tree validity.
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". 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);
"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."
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_INCOMPLETE validity type." in addition, the affected validation methods have been changed appropriately to return the validation state.
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.
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.
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?
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.
We would prefer that the method be named "getDefinedElements" since XML Schema distinguishes between element declarations and types.
This was renamed.
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 declara tions in the "grammar"/schema? If so, the description should probably be more pr ecise. Also, will this list include names from both global and local elemen t declarations in XML Schema?
This description now reads "returns list of all element information item names of global declaration, belonging to the specified namespace."
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?
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."
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.
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".
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?
Although the introduction of validation states cover the possible values for [validity] in the PSVI, they provide no means, as far as we can tell, for communicating to the application the values of the [validation attempted] property. We feel that this property provides very useful information about the validation attempted, and believe users would want access to this information in their applications. We would encourage the DOM WG to consider adding this capability.
We regret that the [validation attempted] property won't be accessible. We find it unfortunate that the DOM does not provide a generalized mechanism for accessing infoset or extended infoset properties, as this would not be an issue if such a mechanism were available. Having said this, we accede to the DOM WG on this issue, and consider this issue closed.
the validation methods now all return a validation state constant. an appendix describing the validation outcomes has also been added.
We considered your suggestion and have decided to not add such functionality since we think this is too XML Schema-specific, and might lead down a slippery slope, e.g., what else do we provide from PSVI.
This issue has been closed.
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?
the beginning sentence now reads "determines if the node is valid relative to the validation type specified in valtype..."
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.
the validation methods now all return a validation state constant. an appendix describing the validation outcomes has also been added.
Section 1.3, Interface NodeEditVAL, method canAppendChild Shouldn't "Determines whether the Node.replaceChild operation ..." be "Determines whether the Node.appendChild operation..."?
This has been corrected.
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?
The phrase "...canonical lexical representation of the enumeration components" isn't quite correct. In addition, upon further consideration, we would suggest that the canonical lexical representation be recommended, but not required. The reason for this is the fact that there are some XML Schema datatypes for which no canonical form is specified; for example, see open Rec Issue R-98.
Given this, we propose wording such as:
"If the schema is an XML Schema, this is a list of strings which are lexical representations corresponding to the values in the [value] property of the enumeration component for the type of the attribute or element. It is recommended that the canonical lexical representations of the values be used."
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.
Agreed.
Section 1.3, Interface NodeEditVAL Should this interface extend the Node interface? (similiar to the way in which the RangeVAL interface extends Range)?
No, we wanted to avoid diamond inheritance.
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?
This action seems reasonable to us. One further question on the statement "If no schema is found, VAL_TRUE is returned". Do you mean that VAL_TRUE would be returned on a call to canAppendChild, for example, if the schema isn't available? We assume that VAL_UNKNOWN would be returned for the method nodeValidity in such a case - is this correct?
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.
Yes, to both questions.
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?
We reviewed the description of the representation of wildcard namespace constraints in the latest spec, and believe there is an error. From the current spec:
To expose wildcards, the NameList returns the values that represent the namespace constraint:
{namespaceURI, name} is {null, ##any} if any;
{namespaceURI, name} is {namespace_a, ##other} if not and a namespace name (namespace_a);
{namespaceURI, name} is {null, ##other} if not and absent;
Pairs of {namespaceURI, name} with values {a_namespaceURI | null, ##other} if a set whose members are either namespace names or absent.
There is an error in the last bullet, as the pair would always seem to require ##other, even if the value is intended to represent just a namespace name.
a section on wildcards was added, along with the appropriate changes in the attribute descriptions.
Agreed on the last bullet; it should be:
Pairs of {namespaceURI, name} with values {a_namespaceURI | null, null} if a set whose members are either namespace names or absent.
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?
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.
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?
It is still not clear to us exactly what "context" means. And is "content" in the phrase "...but depending on the content..." referring to the content model of the element node on which this method is being invoked, or does it refer to the content model to which such an element node belongs? In other words, does this look for element declarations "below" the current element node, or at the same level as the current element node? Also, we assume that this method will always return true if there is a global element declaration for the name/namespace specified, regardless of the particular element node on which the method is being invoked (i.e. even if the global element is not allowed by the "content model"). Is this correct?
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."
Agreed.
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"?
What do you mean by "*the* simple type definition"? Elements whose types are simple type definitions would have a content type of VAL_SIMPLE_CONTENTTYPE. But so would elements whose type is complex with simple content. Perhaps this definition should instead state: "If the schema is an XML Schema, then the element has a content type of VAL_SIMPLE_CONTENTTYPE if the type of the element is a simple type definition, or the type of the element is a complexType whose {content type} is a simple type definition."
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."
Agreed.
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".
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."
Section 1.3, Interface CharacterDataEditVAL, isWhiteSpaceOnly; Should "true if content only whitespace; false for non-whitespace" read "true if contains only whitespace; otherwise false" ?
This now reads "determines if character data is only whitespace" and the method returns a validation state constant.
Last update: $Date: 2003/07/24 17:27:02 $