Neil Graham wrote, On 30/04/2003 1.41:
> 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
>>> so, 
>>>and you're using a standard XMLReader implementation of some sort, then
>>>how 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!  :)

:-D

>>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?  :)

Yeah, I know... I read about XNI, so I'm aware of the reasons it was 
created...

> 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...

...which brings us to the real catch22 problem, as Xerces needs XNI but 
all systems out use SAX. Why not only extend SAX? (ignorant mode)

>>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?

Is it impossible to do validation of a document from a SAX stream? Or is 
XNI compulsory?

Is it possible to do XInclude from a SAX stream? Or is XNI compulsory?

Is there a real possibility of hacking the SAX pipelines to make this 
happen for *some* components like validation or XInclude?

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

No, you have been very on-the-spot :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------