xsl-list
[Top] [All Lists]

Re: [xsl] Large content rendering in XSLT

2008-05-19 22:43:47

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.

Ok, this sounds very reasonable for an XSLT application.  The example I
mentioned isn't using xsl:copy-of or xsl:sequence, but is doing the
higher overhead of xsl:apply-templates -- so more work than it sounds
like you might be needing to perform in your application.

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?

If you mean apply XSLT to existing HTML markup, the answer is that
it depends.  If your HTML happens to be well-formed XML, then you
ought to be able to process it directly in XSLT.  If your HTML is
like 90% of the markup out there, which uses the SGML form (open
tags w/o closing tags in some cases), then you'd need to run the HTML
through a fix-up process before you could process it in XSLT.  We do
something similar for another application here, and have found that
TagSoup (http://home.ccil.org/~cowan/XML/tagsoup/) works pretty well,
though there is a penalty paid in over-head.

It's possible to hook TagSoup directly into a processing stream,
feeding the results into an XSLT transformation engine, but instead of
performing the fixup from SGML to XML on-the-fly it might be prudent
to consider the feasibility of using something like TagSoup or SX
(http://www.jclark.com/sp/sx.htm) to pre-process all of your HTML into
well-formed XML, thereby reducing the CPU cycles needed when serving
requests.

XSLT 2.0 can load and serve unparsed text (non-markup text) directly.

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,

Well, many XSLT engines can certainly pull data from remote locations
w/o needing a lot of infrastructure.  Saxon, for example, can certainly
pull data over HTTP (e.g., sending an HTTP GET request to a web service).

Jim

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James A. Robinson                       
jim(_dot_)robinson(_at_)stanford(_dot_)edu
Stanford University HighWire Press      http://highwire.stanford.edu/
+1 650 7237294 (Work)                   +1 650 7259335 (Fax)

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>