xerces-j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Graham" <ne...@ca.ibm.com>
Subject Re: [ANN] XInclude processor for xml-commons
Date Tue, 29 Apr 2003 23:41:32 GMT
Hi Nicola Ken,

>> In your original post, you'd mentioned that you'd implemented this as a
>> "SAX filter"; did you mean that it's an XMLFilter implementation?  If
>> and you're using a standard XMLReader implementation of some sort, then
>> do you do XInclude processing before validation?

> Ooooh, opening a can of worms ;-)

Both commons-dev and xerces-j-dev have been really quiet lately; about time
for some activity!  :)

> Yes having used XInclude I can solemly state that XInclude has to occur
> before validation. The question is: should a parser validate? ;-)

> The fact is that Processors like Cocoon will always have other methods
> to use before a validation, so what we (Cocoon) need is instead a
> validating transformer, or something like that.

> Not that I'm defining solutions, just that Xerces is monolithic seen
> from a SAX-adhering processor world.

I see what you're saying, I think:  you like the idea of a componentized
parser that operates in a pipeline, but you wish that SAX had been used as
the glue for such a beast, rather than its own API.  Right?

And if SAX had seemed rich and complete enough, and had it supported the
kind of configuration-management facilities that are needed for such an
arrangement, I imagine that's the road we would have gone down.  But it
isn't/doesn't, so what was there to do?  :)

So I guess I'd turn the question around:  If using SAX means you're stuck
with monolithic-looking parsers, but XNI would give you a parser with all
kinds of flexibility, maybe using XNI might merit consideration?  :)  Sure
it would bind you to a specific parser (until other parsers begin to use
XNI :)) ), but if you write your own SAX-glued parser then you're stuck to
that anyway...

> Dumb proposal: why not a XNI2SAX Filter that uses an XNI processor for
> SAX?

We already have one:  org.apache.xerces.parsers.SAXParser; heck, it even
understands both SAX1 and SAX2!  :)  The trouble is that, once you're
emitting SAX, you're not in the Xerces pipeline world anymore; so this guy
is only useful at the end of such a pipeline (whatever XNI components that
pipeline has in it).  So there's no way of putting a Xerces validator after
that component, for instance (to do so would kind of defeat the point of
XNI).  Does that explain anything?

Here's hoping I haven't let too many more worms out of that can...

Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com

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

View raw message