On Wed, Jul 28, 2004 at 10:12:20AM -0700, Jeff Greif wrote:
> Unfortunately, the 'minimum set of checks' depends upon what you're
> validating against.

Precisely - I'm trying to establish what would be a good thing to validate
against for this purpose :-)

> If it's XML Schema, the locality of the constraints of
> that language means it usually** suffices to validate the Entry element
> against its type.  But this requires that you know, without parsing the
> entire document, the type of the Entry element.  If the language supports
> cooccurrence constraints, there could be one that said no Entry element was
> supposed to have more than one <name> child if some other element somewhere
> else in the tree had a certain property.  Much more of the document would
> need to be validated in that case.

Indeed.

> A feasible conceptual mechanism (leaving aside performance problems on large
> files) would be to update a PSVI-decorated DOM, and revalidate (using DOM
> Level 3 APIs) the nodes rooting the altered subtrees.

I had not come across DOM validation until now. The spec mentions W3C Schema
and DTD almost in passing; is it intended to work with any validation
mechanism, or just these two? For example, with Schematron, it seems quite
difficult to determine what are the valid children you could add at this
point in the tree.

> **: I believe that a non-local constraint involving keys and references in
> XML Schema, such as requiring each name child of an Entry to be a reference
> to an existing key elsewhere in the document, would create additional
> validation requirements.

Sure, but in the case of inserting a new subtree into an existing document,
all you'd have to check would be that any references within the new subtree
pointed to existing nodes in the existing document. Clearly, no nodes within
the existing document will point to nodes within the new subtree, as it
hasn't been inserted yet.

Aside: perhaps some of the "XML fragment" stuff may be relevant here, but it
seems that that is an abandoned project.

Regards,

Brian.