[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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? 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: 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|