David,
I agree that a multi-stage XSL processing may improve maintainability of web
sites or other presentation systems. Your example is pretty illustrative.
However, I don't believe it should be done within a XSLT processor. The
processor may support this kind of processing by leaving the result tree in a
memory to be used later, but a logic of such a processing seems to be beyond the
scope of processor. This is why it is also beyond the scope of XSL specs.
Sablotron now allows to leave the resulting text stream in a memory to be used
again; we call this feature named buffers. Storing a parsed tree instead of the
stream is a possible optimization (but the parsing is just a small fraction of
the overall processing time currently).
If you need more than just to couple XML data and stylesheet using the
xml-stylesheet instruction, you probably have to use some kind of application
framework to control the flow of transformations or you can try to create a
simple control application of your own.
Regards,
Petr
"Schuetz, David" wrote:
> In my continued experimenting with Sablotron, I've come against what I see
> as a need for a recursive sort of processing of an XML/XSL fileset.
>
> Basically, I've got an XML data type that requires some specific logic on
> the display side, so I can display different aspects of the file (one page
> for everything, others for different views of selected data). Works great.
> But then I've also got two output styles I'm working with (fancy and plain
> HTML). So I need to duplicate all the logic for both the fancy and the
> plain output XSL systems. This could start to become a problem quickly, as
> whenever I decide to change the structure/content of the output, I have to
> modify multiple XSL sheets.
>
> I was wondering if there is any way to split this into two separate stages.
> That is, have one style sheet to do the conversion from data-XML into my
> more standard XML language for the web page. That's where all the
> application-specific XSL stuff would live. That output would be another XML
> file, that would then be fed into the appropriate XSL sheet for final output
> rendering.
>
> The best I can tell, Sablot's output stays as output -- that is, if I
> transform XML into a new XML, that second XML set won't get processed by the
> current Sablot instance. Or am I missing a key command somewhere?
>
> Basically, I'd like to see something like this:
>
> <RAWDAT>
> <GROUP>
> <NAME>This is Group A</NAME>
> </GROUP>
> </RAWDAT>
>
> get translated to
>
> <DOCUMENT>
> <SECTION>
> <TITLE>This is Group A</TITLE>
> </SECTION>
> </DOCUMENT>
>
> which would then get changed to
> <HTML> [.....]
> <HR>
> <H1>This is Group A</H1>
> [.....]
>
> But I'd like it to happen all in one swell foop. The alternative is to run
> Sablot twice in a row, but if I do that on stuff that doesn't need the
> initial conversion, then I lose all markup and get just flat text (as I'd
> expect, since I don't have any XSL code to keep HTML as HTML). And what
> happens when I have a need for a three-stage conversion?
>
> Does the XSL spec support this mode of operation? If so, does Sablot? If
> not (for either question), is there a good way to do this?
>
> Thanks!
>
> david.
--
Petr Cimprich
Ginger Alliance Ltd.
www.gingerall.com
