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: Sat, 04 Mar 2000 17:50:45 -0800
- Organization: The Qub Group
- References: <NBBBJPGDLPIHJGEHAKBACECLFAAA.martind@netfolder.com>
- Reply-To: xsl-list at mulberrytech dot com
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