[Fwd: FW: DOM 3 Validation: Separation of features]

Responses are below.

Thanks,
Ben

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

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