Re: [xsl] Large content rendering in XSLT

["Senthilkumaravelan K" <skumaravelan@xxxxxxxxxxxxxx>]

We do not have any complicated logic in XSLT and it just select of a
node a copy of the node.
And I do not need to evaluate the text content and we do not do any
decode as well.

Actual content of my text document would be something like Terms and
conditions of any web site.
We need to format it in case of HTML part and use the same data for
text part for  plain text as well.

I am looking for advise/suggestion is the XSLT fits this kind application.
In your example you have mentioned that you are reteieving the
documents over HTTP .
Are your doing <xsl:copy-of-value
select=document(http://mydomain.com/page.html)"/>

If I go through this kind of approach ,need to have all of content
should be well-formed and all xslt
rules that apply. Is there any way to apply XSLT for the existing HTML content?

The reason have mentioned upstream system does need to send the larger
text for every call they make for transformation and further
processing. The actual static data should be pulled from the external
system and used as part of the mimemessgae construction,

Hope I am clear on my specification. Let me know if you need more input.

Thanks



On Mon, May 19, 2008 at 8:18 PM, James A. Robinson
<jim.robinson@xxxxxxxxxxxx> wrote:
>
>> We would like to transform the XML data into HTML and TEXT output and
>> construct a Mimemessage using java. One of the element would have more
>> of Text data like something run into 3-5 page of text. We would like
>
> Depending on how complicated your logic for the transformation needs to
> be, your description so far appears to be reasonable for an application
> of XSLT.
>
> Do you need to simply output the text portions of the document, or do you
> need to actually evaluate the text?  I ask because heavy manipulation
> of large amounts of xs:string data might not be the best thing to do
> in XSLT alone, depending on the complexity (e.g., if you're having to
> perform decoding operations).
>
>> to format the text into HTML and text and tranform the same .
>> I have taken refund policy  as example ,cause it is easy to understand
>> the context.
>> Application upstream does not want send text data for every request.
>> It should be presisted and ready to use .
>
> I'm not sure what you mean when you say an upstream application does not
> want to send text data for every request, or how you think this may have
> an impact on the question you are asking.  If you could clarify by
> perhaps sharing some example XML and brief descriptions of the kinds of
> manipulations you will need to perform, that might help people here give
> you some advice.
>
> You might also want to give us an idea of what your performance and
> resource requirements are (E.g., do you require response times in seconds,
> milliseconds, or microseconds? Are there are limits on memory usage?)
>
> I'm not sure how helpful this is, but I can describe a fairly simple
> XSLT transformation we are running here which might give you a sense of
> the size of documents which can be reasonably manipulated with XSLT.
>
> In this simple system we have a number of documents which have a
> hierarchical relationship.  They are Issues which have child Article
> documents.  We have written an XSLT stylesheet which can dynamically
> retrieve a given Issue and all its child articles, returning a composite
> document.  The XSLT actually retrieves all of its documents over HTTP
> from a secondary server (so it isn't reading the files off of local disk),
> running each through a fairly light transformation.
>
> Using Saxon-SA 8.x on a dual-core AMD Opteron 1210 machine w/ 8 gb
> memory, it is possible on the first request to transfer a 4-megabyte
> compound issue document (composed of about 335 individual documents)
> in a little under 5 seconds, with an initial response (meaning when the
> first part of the document starts coming back), in .03 seconds.
>
> After the first request the individual documents have been pulled into
> a cache (they've been converted into the native Saxon TinyTree format),
> and the same request takes, on average, around 2.1 seconds to transfer.
> As with the initial request, Saxon is able to start feeding back the
> response within .03 seconds.
>
>
> Jim
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> James A. Robinson                       jim.robinson@xxxxxxxxxxxx
> Stanford University HighWire Press      http://highwire.stanford.edu/
> +1 650 7237294 (Work)                   +1 650 7259335 (Fax)