Neeraj Bajaj - Javasoft wrote:
> Does that mean once we are ready with this kind of tool we
> can override the functionality of "BasicparserConfiguration" ?? and
> "StandardparesrConfiguration" of Xerces2.
Sure. But there's nothing stopping you from writing a new
XMLParserConfiguration from the ground-up today. Having a
configuration file format (and a generation tool, perhaps)
would just make it easier to do so.
> i was thinking what all XML config file should contain, list of
> a)New components (that implements XNI Component interface) and standard
> components of xerces2 for the pipeline.
Not just those that implement the XMLComponent interface,
but also those properties that other components depend
upon. For example, the SymbolTable is not a "configurable"
component so it does not need to implement the XMLComponent
interface. But it still needs to be in the configuration
with a way for the configurable components to queryit.
> b)Properties and features recognised by new parser coniguration.
> c)Some kind of option for the usage of "SymbolTable","GrammarPool" in this
>configuration.
Covered by my previous comment.
> or do we need to set something more for the configuration of parser as per XNI ?
Actually, the XMLParserConfiguration is a black box.
The parser instance that uses it has no idea what is
inside the box, nor does it care. The only thing it
really cares about is that you can start parsing a
document by calling parse(XMLInputSource) and that
document information comes out the other end. Usually
the parser is registered as the document and DTD
handlers on the parser configuration but it doesn't
have to be.
This means that you don't have to use the XMLComponent
interface at all. It's really there as a convenience
so that we can build up a library of compatible parser
components.
> 1.is it possible in XNI,that once i set the configuration and it is loaded, i can
>change it
> again during the parse OR for next parse ?
Yes. The parser configuration is a black box. What you
do on the inside is of no concern to the parser that
generates SAX events or builds DOM trees, etc.
> what i could understand is that they are different components (handlers) configured
>for
> pipeline , so that document event can be passed to the next component as configured
>in
> pipeline and if in b/w component doesn't return anything or the parser is configured
>not to
> use that component, then the next component will be used in the pipeline.
Currently, the standard parser configuration used by the
default Xerces2 parsers have a particular configuration
and do not change that configuration ever. But you could
write a configuration that mutates, if you wanted.
> if yes, then why parser being final target of events doesn't implement XMLComponent
>of XNI.
The parser is not a component, nor should it ever be
added as a component to the parser configuration. If
you do, you'll end up getting into an infinite loop
because the application will set a feature or property
on the parser, the parser will forward that to the
parser configuration, and the parser configuration
will again forward that information to all of the
components. When the parser configuration notifies the
parser, the parser will forward it to the parser
configuration and you have an infinite loop. Infinite,
at least until your stack overflows! ;)
> 3.To add to that,
> what is the basic requirement for a new component to be the part of pipeline ?
Whatever you want it to be! However, there are certain
requirement in order to be used together properly with
the standard parser components that make up the Xerces2
reference implementation.
If you extract the "xerces_j_2" branch from the CVS
"xml-xerces" module and build the documentation for
Xerces2, you'll be able to get a lot of information
about XNI and the parser configurations with samples.
If you haven't done so already, I would suggest
reading over this material and let me know where
you think it is unclear or where information should
be added. And once we (finally) get the beta release
out, everyone will be able to get access to this new
documentation much easier.
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
