Everyone,
Okay, I have added the scanner interfaces and made the changes
to the Xerces2 reference implementation to implement this. I
built it and ran it through the OASIS test suite. Nothing seems
to have broken so I went ahead and committed the changes.
This is actually quite cool because of the following reasons:
1) We can define a parser conifugration's pipeline dynamically.
For example, through an XML config file or something. That
way people could create new configurations (e.g. adding an
XInclude filter in the pipeline) by tweaking the standard
configuration file instead of having to create a new
XMLParserConfiguration duplicating a lot of code.
2) We can remove some of these extraneous class layers from
the parsers package. Right now each parser type, DOM for
example, has a base class called "AbstractDOMParser" that
takes an XMLParserConfiguration object in its constructor
and the normal "DOMParser" which uses the standard
configuration.
We made the separation because to compile the standard
configuration, it depends on the various Xerces2 parser
components. Which means that the *parser* class would
have relied on these same classes just to compile --
something that hurts the layerability of the whole
thing.
So now we could define the standard parser configuration
in some kind of config file which gets loaded dynamically
or some such thing. Perhaps using a META-INF/services
kind of file??? I guess we could do this anyway without
the new scanner interfaces. But now that we have them,
I'm getting all sorts of crazy ideas running through my
head about the possibilities! :)
Next, I'll be updating the XNI Manual in the documentation to
detail these new interfaces. (I'll have to force myself 'cause
I'm really feeling burnt out writing so much documentation. :)
Anybody out there want to help with the documentation? We
still need some docs on how to build parser configurations
that use the Xerces2 standard components -- because they have
certain dependencies, etc. So that's something that still
needs to be done.
Ted,
You done with that grammar for the pipeline setup, yet?
Now that we have the scanner interfaces, I could whip up a
sample that implements this "dynamic" parser configuration
that's possible. When I tried this before (and stopped 'cause
we didn't have any scanner interfaces), I came up with a DTD
grammar for the purpose.
<!ELEMENT parser (component*,xml?,dtd?)>
<!ATTLIST parser name CDATA #IMPLIED
version CDATA #FIXED '0.9'>
<!ELEMENT component EMPTY>
<!ATTLIST component id ID #REQUIRED
class CDATA #REQUIRED
property CDATA #IMPLIED>
<!ELEMENT xml (source,filter*)>
<!ELEMENT dtd (source,filter*)>
<!ELEMENT source EMPTY>
<!ATTLIST source idref IDREF #REQUIRED>
<!ELEMENT filter EMPTY>
<!ATTLIST filter idref IDREF #REQUIRED>
I'm hoping that you can sort of figure out how it works by
looking at the grammar. Basically, you have a number of
<component>s with an ID and then you construct the <xml>
and <dtd> parsing pipelines from <source>s and <filter>s
that reference the components using an IDREF. It's very
simple, but I was just writing it as an XNI sample. Not
something that was too complicated.
Anyway, let me know where you were heading with this idea.
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
