[Xerces2] Document Fragment Handler

[Andy Clark <an...@apache.org>]

In my last post, regarding the refactoring of the XNI Core
interfaces from the parser configuration stuff, I mentioned
that the XNI Core currently includes interfaces for defining
document fragments. Specifically:

    interface NamespaceContext
    interface XMLDocumentFragmentHandler

And these are used to communicate information about document
fragments. A generally useful thing. And I mentioned that I
planned on using this standard interface for implementing
the XPath matchers needed for supporting XML Schema identity
constraints. But there are other uses, which will become
apparant as I continue. Anyway...

The XMLDocumentFragmentHandler contains many of the same
methods as the XMLDocumentHandler methods. But I want to
talk about the startDocumentFragment method. Currently this
method takes one parameter, a NamespaceContext object, so
that it can figure out the namespace context separate from
having received all of the document callbacks.

However, only passing the namespace context is rather
limited in certain situations. For example, what if the
handler needs to perform validation of the document
fragment? At first glance you might think that having the
namespace context is enough but think about the following:

  * verifying ID uniqueness, IDREF validity
  * ENTITY/ENTITIES/NOTATION attribute values
  * Schema anonymous types, etc.

All of these (and more) suggest that there needs to be
more information communicated to the document fragment
handler than just the namespace context. But there is
no possible way to define the necessary context for all 
of the world's use cases for document fragments. And I
don't propose that we try.

So my first inclination is to define a new interface,
XMLDocumentFragmentContext, which is just an empty
interface. (We can still define NamespaceContext as a
sub-interface because it's very common and covers the
common use case for document fragments.) Then the 
startDocumentFragment method would be passed a generic 
context object and it would be implementation dependent 
what kind of context object is passed to the handler.

A validating document fragment processor would then
pass something like a ValidationContext to the fragment
handler that contains all of the information needed to
do validation of the fragment. Seems reasonable, right?

Well, the question I have is this: what purpose does
having an empty XMLDocumentFragmentContext do you if
you have to create a custom implementation of the
context anyway? You could very well just create a 
custom context from the NamespaceContext interface
and go from there. The only answer I can come up with
is to keep the design clean but this doesn't seem like
reason enough.

Anyway, this has been rattling around in my brain so
I thought that I would see if anyone has comments or
ideas.

Thoughts?

-- 
Andy Clark * IBM, TRL - Japan * andyc@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org