This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT vs Omnimark
- To: xsl-list at mulberrytech dot com
- Subject: Re: XSLT vs Omnimark
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Sun, 05 Mar 2000 13:05:54 -0800
- Organization: The Qub Group
- References: <NBBBJPGDLPIHJGEHAKBAKEDAFAAA.martind@netfolder.com>
- Reply-To: xsl-list at mulberrytech dot com
Hi Didier,
> Paul said:
> I think that's not because of java. I think that's because they do not
> support pull ( or they do? How do they handle look-ahead pull? Do they allow it?).
> That means they are 1 step behind XSLT. ( and also Omnimark has
> not that much advantage comparing to perl, because recursive push
> could be implemented with hand-made perl layer).
> Didier replies:
> If you read again my post, you will notice that the following sentence
I did read your post.
> >"But this is precisely these technical
> > features, and the fact that modern browser includes or will includes XSLT
> > that makes XSLT the worse competitor to Omnimark. They have an advantage
> > compared to XSLT, their processor is tremendously faster than most XSLT
> > processor written in Java.
>
> Mean that I was talking about XSLT engines written in Java that are not fast
> enough :-)
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?
> Paul said:
> Pull is hard. Smart combination of pull-push is a killer. XSLT did the right
> thing
> allowing push-pull combination, but not the ideal thing ;-)
>
> Didier replies:
> But Omnimark does both push and pull and so do DSSSL. So where's the point
> here?
I see no look-ahead pull in Omnimark. Where is it ? Actualy, that was the
only question I had about Omnimark and unfortunately I got no answer.
> Paul said:
> So far I think Omnimark has only push-part ... But in case Omnimark
> has assignable variables ( so-called side-effects ), that means they could
> be
> realy better than XSLT for some applications!
>
> Didier replies:
> Omnimark has also constructs to do some pull as well as push. Please take a
> look that their documentation.
Could you please help me?
What particluar part explains how to do look-head pull? Their documentation
is huge and unstructured.
Look-ahead pull is
<xsl:template match="/doc/first_element">
<xsl:value-of select="/doc/last_element">
</xsl:template>
Rgds.Paul.
PS. Another big question is the idea of 'messy' processing itself. I mean that
processing XML with regular expressions is actualy a logical hack. XML is
about the content, stylesheet is about the processing, that means when
some processing is done with regular expressions ( 'direct' processing
of the content) I think that means that XML schema of the processed
document is not ideal and it is better to change the schema. When
'direct' manipulation of the conetent is unavoidable ( for example,
uppercasing the first letters when rendering something as 'title' ) -
I think it is consistent to utilize the extension function for such
things. That's why I think XSLT is beautiful ( because it is consistent
with the XML model. XML model is 'string' - based. Is it good or not -
I don't know. I think it is good. )
Actualy the 'direct processing' usecases raise another issues ( like
adderssing characters with Xpath, what is 'good' 'atom' - is it string
or character e t.c. ) - discussing those things could become a
serious offtopic ;-)
What I wanted to say is that I think XSLT is consistent and beautiful,
forcing separation of content from processing ( presentation ).
Regular-based tools are crushing the basic XML message.
( so does perl ;-)
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list