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 documents. 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. Carsten > -- > Torsten > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
