Re: XSLT vs Omnimark

Hi  Didier ,
 
> Paul said:
> C) ...  perl could be considered to be a rule-based language, like awk.
> Awk is a "rule-based language for streaming processing of documents".
> Right? So is perl  ;-)
> 
> Didier replies:
> It depends off course of your definition of rule based languages ;-) Let's
> then explain mine:
> a rule based language is a language where procedure or set of instruction
> are run when an external event occurs. These languages react to things. We
> can also say that a rule base language is also an event based language.
> Among rule based languages:
> 
> a) CSS

Oh ... 

> b) DSSSL
> c) XSLT

It appears that we have kind of different view on XSLT. 

I would agree that <apply-templates/> push  part 
of XSLT is very much "rule based". 

But pull part of XSLT  ( <value-of select="/pull/from/some/place"> or, 
for example <xsl:for-each> ) could hardly be named 'rule based'. 
Otherwise we should end  considering any  existing language 
to be 'rule based'. Right ?

> e) Omnimark

Well ... because you place CSS into the same box with XSLT, 
I think you could place Omnimark into that box ;-) 

To me CSS and XSLT are very different. The first one 
is push-only, the second allows combinations  of pull and push.

> Paul said:
> Aftre you's and Vincents postings I now think that both comparsions are
> legal. ( and it is not an offtopic here ;-)
> 
> Omnimark vs XSLT and  Omnimark vs Perl. Omnimarks grabs a bit from
> Perl and a bit from XSLT.
> 
> Didier replies:
> To be fair I would say that yes the procedural part of Omnimark is remind
> PERL. But because Omnimark was there a long time before XSLT, we can say
> that XSLT grabs a bit from Omnimark (the rule/event based mechanism).

I disagree here. I think the real power ( and the invention) of XSLT 
comes from pull part, not from push ( or better to say - the ease of combining 
those two. I think I'm quoting Clark Evans here, but I agree with his 
sentence 100% ;-)  ) . 

Push concept is *so* old ( awk, sed ) that it more likely belongs to Kernighan, 
not to Omnimark ( also  the concept of push-processing is so obvious, that  
I think saying that XSLT grabs something from Omnimark is not reasonable). 

On another hand,  I'm sorry saying that Omnimark "grabs" something from 
XSLT. That's wrong, of course. I was better to say that Omnimark 'shares' 
some well-known ideas with awk , XSLT  - whatever. ;-)

> Paul said:
> But it does it in 'perlish' way, lacking XSLT's conceptual beauty.
> That's what I meant saying that Omnimark is 'eclectic reincarnation of
> perl'.
> 
> Didier replies:
> I do not follow you Paul. In which way Omnimark is lacking XSLT beauty since
> XSLT have the same underlying conceptual framework as Omnimark. 

I disagree they are the same. 

The beauty of XSLT is that:

One should know how to use only 3 constructions to get understanding 
on the XSLT model and learning just 3 constructions gives  a lot of power.

The silver-bullet XSLT constructions are:

a. <xsl:apply-templates>
b. <xsl:template match=... mode=... >
c. <xsl:value-of select=...>

(a) and  (b) give powerful push, (c) gives powerful pull.

Just 3 constructions - and you could do a lot of  cool things!
That's beautiful ! 

Not yet talking about the drawbacks of  XSLT, but I should 
point that XSLT was the most elegant concept  that I saw  for 
a very long time. 

The concept of XSLT as I understand it  is: 
"awk is good, but push-only is not enough". ;-)

> I would say, however that the main advantage of XSLT compared to Omnimark 
> is the presence of XPath in XSLT which is a better pattern matching expression 
> that the one used by Omnimark. But if you looked closely to the example I gave in the
> last post you would see that they have the same conceptual framework.
> 
> So the following construct:
> 
> <xsl:template match="topic">
> <p>this is topic</p>
> </xsl:template>
> 
> is triggered the same way as:
> 
> element topic
>   output "<p>this is a topic</p>"

I see what you mean. That's awk, right? Just extend the regular expressions 
a bit and allow them to be applied for not only line, but allow largest  
chunks ( separated  not by newlines, but <tokens> ). I could write such 
layer in perl  pretty  fast.  It will take not longer than a week and will be 
more flexible, because it will not be hardcoded. I just don't see any 
purpose in reinventig the push-only wheel, because ( as XSLT shows)
push is not enough. ;-)

> There is no for or while construct here, just a rule declaration which is
> triggered by the pattern match mechanism. Moreover, Omnimark (and do not
> forget that Omnimark and DSSSL where the predecessors of XSLT and that this
> latter did not brought any novelty on this facet - only with XPath, the
> pattern match expression). It is then possible to modify, as well as with
> XSLT, the structure of the resultant document with:
 
> element topic
> output "<p>this is a %c topic</p>"
> 
> the construct %c is equivalent to the <xsl:apply-templates/> construct.
> Thus, when the source tree is processed, the other rule matching the current
> processed nodes will have their output included where the %c is located as
> it is the case in XSLT actually with <xsl:apply-templates/>

Oh. So they realy got 100% of push-part of XSLT implemented.  Yes, the ability 
to re-invoke matching recurcively was not that clear in awk. 

Unfortunately, plain-push-based processing causes messy and not easy 
to support stylesheets ( even it has kind of 'better scalability' ).

I agree. OmniMark is a step forward, if  comparing it to awk. To me  *this*
step is not worth switching from perl ;-)
 
> So, Paul, as you may notice now, Omnimark and XSLT are really close cousins,
> that Omnimark is closer to XSLT than to Perl and finally that Omnimark
> Marketing people are due for some training since their real enemy is not
> PERL but more XSLT.  This is rational thought, but as we both know the market
> is not as rational and in terms of market share PERL is enormously bigger
> than the one of XSLT. We also both know that marketing guys are number
> driven and that market share is a indicator, for them, of who's the
> competitor not the technical features. 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. 

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).

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 ;-)

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! 

... until ... somebody will write XSLT:perl with something like saxon:preview ;-)

Thank you very much for explaing that Omnimark actualy has <xsl:apply-templates/>
hidden somewhere ;-) 

It seems that until somebody will write the similiar layer in perl  ;-) Omnimark 
could be realy good for some trivial processing of a huge documents.  ( actualy, 
I think I'l still do *such*  tasks  in perl faster than in Omnimark, but that's because 
I have to spend years with perl).

You definately changed my mind on Omnimark. After your explanations, 
I now think that in existing world Omnimark could be realy a nice  tool for 
somebody who does not know perl, but wants to  make some relatively 
simple processing of some hude XML document  / data stream !

Rgds.Paul.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list