Re: DOM revalidation: design/ open issues

[Joseph Kesselman]

On Thursday, 06/06/2002 at 04:21 AST, Elena Litani <[EMAIL PROTECTED]> wrote:
> > I'd still really like to have a simple example of assembling XNI
> > components into a Configuration that would show me how to take my
> > XMLDocumentScanner and XML*Handlers and hook them up on either side of
> > a validation.
>
> I have doubts that it is useful to have such configuration in Xerces.

We agree that we disagree.

> We can't know what data model you will be using, so you would need to add
> and re-implement several methods,

We would need to provide an XNIDocumentSource to feed this pipe... but that's unavoidable if we want to pump data back into XNI-based processing.

We would need to provide an XNIDocumentHandler to receive the output of this pipe -- but that's unavoidable if we want to do anything with an XNI stream. I've already got a prototype XNI-based DTM builder written because that's the only way to capture your PSVI annotations; I can obviously use it to catch the output of revalidation too.

But we shouldn't have to reimplement a Configuration just to attach these to the other XNI Components and build our pipeline. That defeats much of the purpose of the Configuration API, in my opinion. We ought to be able to either (a) treat the whole Configuration as an XNI filter, or (b) simply tell the Configuration what our pipeline looks like -- in this case, my source to a moderately standard validator (initialized with an explicitly supplied set of schemas, in my case, but that's a secondary issue) to my sink, and have it ready to go.

> configurePipeline(): to configure pipeline scanner--> revalidation
> handler --> document handler

Exactly. What I'm looking for -- and you may already have, though you didn't use it? -- is a generic Configuration which I can configure via an API rather than by subclassing, and an example or two of how to use it to set up the equivalent of your hardcoded versions... or perhaps the hardcoded ones should be subclasses of this which just call the configuration API when they're constructed.


> parse (): it takes as a parameter an InputSource/or String, so you need
> to add another method that allows to set your data model object on the
> configuration, and use that model to pass to your scanner when the
> parse() method is called.

Not an issue if a configuration can function as an XNI pipeline. Not a big issue for a generic configuration; just indicate the DocumentSource component when you add it to the pipe, and have parse set the input where it can be retrieved and invokel the DocumentSource's scanDocument.

> Btw, you can see that in the pipeline I did not include the namespace
> binder.

Thanks for the pointer. Actually, I wonder whether I might wind up having to do namespace normalization... but I hope that I can continue to leave that for the serializers to deal with rather than needing to make it part of the revalidation process.

> About configurations: the util.ParserConfigurationSettings class is the
> basic configuration. I think the best configuration for you to extend is
> dom.DOMRevalidationConfiguration. It allows to set properties and
> features, but it does not have any components, which you can add: your
> scanner, revalidation handler (XMLSchemaValidator), and your document
> handler.

I'm playing with a copy of that now. I'm slightly confused by the fact that your code doesn't actually seem to make the validator a component within that configuration.... unless this is a side-effect of calling the validator's reset() with the configuration as an argument.


> I have a question for you -- how do you actually create DTM tree? I hope
> it is done from XNI events...?

Main-branch Xalan normally builds from SAX events (and uses a slightly extended flavor of SAX internally). The one exception is that if you pass us a DOM, we attempt to avoid recopying the whole thing and instead build a wrapper directly around the DOM. (We'd like to make that wrapper much thinner, and we have some ideas on how we can do so for the Xerces DOM if we're willing to do yet another special-case chunk of code...)

See Xalan's SAX2DTM.java and DOM2DTM.java, along with the IncrementalSAXSource* classes, for details.

I've got an experimental XNI2DTM, but it is emphatically _NOT_ ready for general use.

______________________________________
Joe Kesselman / IBM Research