Re: XSLT vs Omnimark

["G. Ken Holman" <gkholman at CraneSoftwrights dot com>]

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@CraneSoftwrights.com
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