Re: XSLT vs Omnimark

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