Subject: Re: XSLT vs Omnimark From: Paul Tchistopolskii <paul@xxxxxxx> Date: Sun, 05 Mar 2000 14:30:16 -0800 |
Ken, Thank you *very* *very* much for your excellent posting. I now need to think a lot about Omnimark. It was realy not that easy to understand how many cool concepts are in there, without your posting. Many thanks. Rgds.Paul. ----- Original Message ----- From: G. Ken Holman <gkholman@xxxxxxxxxxxxxxxxxxxx> To: <xsl-list@xxxxxxxxxxxxxxxx> Sent: Sunday, March 05, 2000 2:09 PM Subject: Re: XSLT vs Omnimark > At 00/03/05 13:05 -0800, Paul Tchistopolskii wrote: > >And I said that XSLT engines are slower not because they are written > >in Java, but because they allow look-ahead pull which Omnimark does > >not allow. Is that right? > >... > >Could you please help me? > > > >What particluar part explains how to do look-head pull? Their documentation > >is huge and unstructured. > > The construct in OmniMark is named a "referent". These are user defined > name/value place-holders added to the output. Referents can be scoped > under program control ("begin and end the identification and evaluation of > the set of referents"). > > OmniMark does one pass of the input and one-and-a-half passes of the output > when using referents (only one pass of the output when not declaring that > referents are in use). > > >Look-ahead pull is > > > ><xsl:template match="/doc/first_element"> > ><xsl:value-of select="/doc/last_element"> > ></xsl:template> > > It is the programmer's responsibility to accommodate all output > requirements at the point of the one pass of the input: > > ELEMENT first-element > OUTPUT REFERENT "last-thing" > OUTPUT "%c" > > ELEMENT last-element > SET REFERENT "last-thing" to "%c" > > There is only access to the currently element and its ancestry (all > currently open elements) and no access to other constructs of the source, > thus, the programmer must accommodate forward referencing (your term > "look-ahead pull"). > > It is OmniMark's responsibility (not the programmer) to emit the final file > with all the programmer-resolved referent values (it is an error if a > referent's value is not defined by the programmer). While some term this > "two-pass", I've heard "two-pass" reserved for when it is the programmer's > responsibility to satisfy the second pass, which is not true in this > case. The programmer only sees the result data once; the programmer only > sees the source data once; OmniMark sees the result data the second time > when filling in the place-holders and is *very* efficient doing so entirely > behind the scenes without program intervention, thus I find the term > "one-and-a-half-pass" quite apropos. > > The streaming nature of OmniMark is great for some problems and there is no > overhead for the source document (it is not maintained in memory), only for > the result document (and the intermediate result is on disk, not memory; I > think referent values are in memory, but I'm not sure and it doesn't affect > me as a programmer). > > The tree nature of XSLT is great for some problems and, being result > oriented, has no overhead for the result (it can be instantly serialized), > but does for the source (the entire file has to be accessible at all times; > currently this is in memory for the processors I'm aware of). > > Two different approaches for transformation ... one isn't necessarily > better or worse than the other in the general case or language definition, > just different to the extent that a direct comparison of the two is > difficult. I use both and I choose which one based on the requirement, the > customer, the nature of the data, and the nature of the transformation. > > I hope this has helped. > > ................ Ken > > -- > G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995) > Web site: XSL/XML/DSSSL/SGML services, training, libraries, products. > Practical Transformation Using XSLT and XPath ISBN 1-894049-04-7 > Next instructor-led training: 2000-05-11/12,2000-05-15, > - 2000-06-12,2000-06-13,2001-01-27 > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSLT vs Omnimark, G. Ken Holman | Thread | RE: XSLT vs Omnimark, Didier PH Martin |
Re: XSLT vs Omnimark, G. Ken Holman | Date | RE: XSL stylesheet for printing XHT, James Tauber |
Month |