Re: XSLT vs Omnimark

Subject: Re: XSLT vs Omnimark
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 05 Mar 2000 14:09:39 -0800
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



Current Thread