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
It is the programmer's responsibility to accommodate all output
requirements at the point of the one pass of the input:
OUTPUT REFERENT "last-thing"
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
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.
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,
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list