DOM 3 Validation: Separation of features

First, I didn't intent to write this many messages but it was hard to 
stop after I got started.

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.

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

interface DocumentVAL {
     attribute bool continuousValidityChecking
        setraises NOT_SUPPORTED_ERR;
        //
        //   WD did not provide an exception if you attempted to
        //       set continuousValidityChecking and there was no grammar
        setraises NO_GRAMMAR_AVAILABLE_ERR;
        //
        //   WD also did not have a <setraise> for VALIDATION_ERR
        //      if the document was not valid when attempting
        //      to set to true
        setraises VALIDATION_ERR;


     attribute Node grammar;
         //
         //   If node is not a supported grammar node
         setraises NO_GRAMMAR_AVAILABLE_ERR;

     //
     //   Note: WD's validateDocument() did not have a return value
     //      and had no obvious way of determining if the document was
     //         valid
     //
     //  grammar parameter could be null to use grammar from
     //    document type declaration or schema location hints
     bool validateDocument(Node grammar);
          //
          raises NO_GRAMMAR_AVAILABLE_ERR
}


The remaining interfaces would then have no Validity features and should 
probably be renamed from NodeEditVAL to NodeEdit, etc.

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.

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.

Received on Thursday, 6 February 2003 03:48:30 UTC