Comments on the Validation draft

Forwarding comments from Craig Salter...

Editorial changes:
-----------------
** Fix "1.3. Document-Editing Interfaces" descriptions:
[[
This interface extends the Element interface with additional methods for
guided document editing. An object implementing this interface must also
implement NodeEditVAL interface.
]]
Should be
[[
This interface extends the NodeEditVAL interface with additional methods
for guided document editing. An object implementing this interface must
also implement Element interface.
]]

** Active grammar references:
Remove since there is no definition of Active Grammar. Instead in some
methods be more specific, i.e. 
isElementDefinedNS "in the currently active grammar" should be replaced
with "in the current context".

** contentType SIMPLE_TYPE is missing as well as definition of content
type constants.

Methods modifications
-----------------------
canAppendChild(..) (and other similar methods) should probably have a
"wFValidityCheckLevel" parameter to allow users to specify at what level
validation should happen. It is not clear from the description what kind
of validation should be applied.

Request to add new methods
--------------------------
(1) canWrap(): if user is trying to make text bold they need ask "can I
wrap?":
For example, consider a document: <x><y/>; 
Invoking "parent".canWrap(child_y, b) is essentially asking, can <b> be
child of <x> and can <b> have child <y>  ==> <x><b><y/></b>? 
This method could be implemented in the current spec by using a very
expensive operations:
[a] get all children of "x" 
[b] get all possible parents of "y"
[c] check if "b" is present in both sets.

(2) getNextSiblings/getPreviousSiblings:
Currently if users starts from invalid document there is no easy way to
fix it.
For example, if a content model is Root (A, (B|C), D) and the document
instance is:
<root><a/><d/>. To fix this document user might need to remove all
children of the root first and then try to add those again using (can*)
methods.

The proposed methods should be called on the parent, taking a reference
child as a parameter. Return type is a list of possible siblings.

(3) In XML Schemas because of substitution groups, you often need an
operation that will return a list of alternative elements. Thus, suggest
to add a method parent.getAlternativeElements(replacementChild).

(4) getRequiredAttributes() - often when a new element is created users
would like to add all required attributes to it (to make it valid).

(5) Given that AS model is gone, there is no way to retrieve enumerated
and default values.
Suggest to add: getDefaultValue() and getEnumeratedValues() methods to
the NodeEditVAL interface.

Performance:
-------------
Suggest to change a return types for "NodeList" to the "List of QNames".
The specification requires to create all possible
children/parents/definedElementTypes nodes and these are expensive
operations. Instead it would be more efficient to return a list of
qnames and let user create only the nodes needed. 
Also suggest to remove the getParentElements() method, since some
editors do not provide such operation, probably because it is not that
useful and is very heavy, especially in the case of XML Schemas (since
you need to go expand all content models).

Thank you,
-- 
Elena Litani / IBM Toronto

Received on Wednesday, 6 November 2002 11:50:30 UTC