Subject: Re: XSLT vs Omnimark From: Paul Tchistopolskii <paul@xxxxxxx> Date: Sun, 05 Mar 2000 13:05:54 -0800 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XSLT vs Omnimark, Didier PH Martin | Thread | Re: XSLT vs Omnimark, G. Ken Holman |
RE: XSL stylesheet for printing XHT, Richard Lander | Date | Re: XSLT vs Omnimark, G. Ken Holman |
Month |