cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: XMLByteStreamInterpreter
Date Fri, 18 Jan 2002 16:31:16 GMT

Torsten Curdt wrote:
> While using the XMLByteStreamCompiler and XMLByteStreamInterpreter
> I found that the Compiler will store all SAXevent just fine. No matter
> if it's a valid DocumentFragment of just a fragment of a XML stream.
> But the interpreter assumes that there is always a enclosing
> startDocument/endDocument event and will otherwise only stop
> with an SAXException "reached end of input".
> Since the compiler supports it I'd like to change the interpreter
> not to throw an exception but end normaly on the end of input.
> AFAICS this should have no impact on Cocoon itself.
> (Carsten, I know the caching system makes extensive use of the
> XMLBytesStreamInterpreter. Can you see any problem with that?)

No. The input taken from the compiler is after such a change still
usable with the interpreter. As in the case of caching whole
documents are compiled, this should be now problem.

> If noone objects I'd like to change the interpreter so we have
> the compiler to really record the events and the interpreter to
> recall the events as recorded. (Right now I can record something
> that I cannot recall with the interpreter without getting this
> Exeption)
> If we really want to observe what gets recorded and recalled I propose to
> change the interpreter as mentioned and create two new classes 
> extending the simple
> compiler and interpreter that will make sure only DocumentFragments will
> be recorded and can be recalled.
> What do you guys think?

On the one hand the usage of both components gets more flexible. You
can compile and interprete arbitrary nodes of XML.

But on the other hand we loose validity checking of the interpreted
byte stream. Currently the byte stream must contain a valid XML document.
With your proposed change, the byte stream can contain any block of
XML and I think it is very hard to check if all opened elements are 
closed (or if for each startElement event an endElement event is send).
Another problem I see is that the interpreter is an XMLProducer
and I think that the contract for an XMLProducer is to stream
a whole document. So we shouldn't break that contract.

So it seems better to enfore that the compiler only compiles complete

Another possibility is to explicitly add methods to the XMLSerializer
and XMLDeserializer which tell that not a whole document is processed
but only a fragment.


> --
> Torsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message