Subject: Re: XSLT vs Omnimark From: Paul Tchistopolskii <paul@xxxxxxx> Date: Sat, 04 Mar 2000 17:50:45 -0800 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XSLT vs Omnimark, Didier PH Martin | Thread | RE: XSLT vs Omnimark, Didier PH Martin |
Re: XSLT: Restructuring/Grouping, David Halsted | Date | Re: SVG charts and graphs from XML , Steve Muench |
Month |