synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: Possible improvements in XSLTMediator
Date Fri, 28 Dec 2007 10:23:15 GMT

On 28 Dec 2007, at 10:16, Paul Fremantle wrote:

>> The purpose of TextFileDataSource is actually to implement a text  
>> node
>> (+ <text> wrapper element) that is backed by a temporary file rather
>> than a String/char[] object, thereby avoiding to load the entire file
>> into memory. Maybe we should consider another solution that avoids  
>> the
>> problems described above. The idea would be to use a custom
>> implementation of OMText (that again is backed by a temporary  
>> file). I
>> think that if the custom implementation extends OMNodeImpl and
>> implements OMText, an instance can be added to the Axiom tree without
>> problem, given that the Axiom code never casts OMText to OMTextImpl.
>> An alternative (but less clean) solution would be to extend  
>> OMTextImpl.
> I agree these would work, but I'm not sure why this would be better
> than fixing up the DataSource model. The DataSource approach was
> designed to solve the problem of creating new forms of data-backed
> OMNodes. If it isn't working well enough we should raise this issue
> with the axiom dev team.

The main argument in favor of the custom OMText solution was  
simplicity. There is however another solution that is a bit more  
complicated but that strictly adheres to the OMDataSource model. The  
idea is as follows. What TextFileDataSource does is to construct an  
InputStream that represents the concatenation <text> + text + </text>.  
It then uses this input stream to build an XMLStreamReader. The  
problem comes from the fact that "text" is plain text, not XML text. A  
quick fix could be to wrap the text in a CDATA section (i.e. <text><! 
[CDATA[ + text + ]]></text>), but this doesn't solve the character  
encoding problem. A better solution is then to implement a custom  
XMLStreamReader that synthesizes the following sequence of events:


Since the output of XMLStreamReader for the CHARACTER events is pure  
character data, we don't need to care about XML entities and character  
encoding at that level.

To summarize, the solution would be to replace the custom InputStream  
implementation by a custom XMLStreamReader implementation. This  
XMLStreamReader implementation would have more or less the same  
complexity as the existing InputStream implementation.



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

View raw message