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