Subject: RE: XSLT vs Omnimark From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Sun, 5 Mar 2000 11:20:15 -0500 |
Hi Paul, Paul said: 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 ? Didier replies: Let's put it differently. In most procedural languages the first level of granularity is either a procedure or a function. Thus, a program, is divided in to procedures or functions. In rule based languages, the unit is a rule. For CSS it is called a CSS rule. For XSLT it is called a template, for Omnimark it is called an element rule, for DSSSL it is called a construction rule. Paul said: 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. Didier replies: but both have rules as units. Both are rule based languages. >Paul said: 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. ;-) Didier replies: I am sorry to destroy your illusions Paul but DSSSL and Omnimark got all the concept you mention a long time before XSLT. However, XSLT brought to us a real innovation with XPath. It is a lot more economical than S-expressions, less confusing and could be integrated into a URL. What XSLT brought to us as an innovation is XPath but everything else was there since a lot longer in both Omnimark and DSSSL. These are facts Paul. 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 >"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 :-) 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? 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. Paul said: ... until ... somebody will write XSLT:perl with something like saxon:preview ;-) Didier replies: Why not? and it is possible to do the same thing for JavaScript, VBScript and PythonScript too. With DSSSL we learned that we can do quite sophisticated constructs with S-expressions, with XSLT we learned about a powerful query expression named XPath. In the case of DSSSL a lot of people are not comfortable with Scheme constructs, in the case of XSLT packing procedural construct as tags is not always the most efficient way to do things. So, there is room to improve by including rules, Xpath navigation and procedural constructs in one of these script languages. In fact, such language would be more accessible than XSLT (and also probably more readable by a big chunk of the programming population). XSLT is just a step in our learning journey, there is still place for improvements. Paul said: 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). Didier replies: And this would be a sufficient reason to do so. Paul said: 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 ! Didier replies: Paul, you can do very sophisticated processing on large document with Omnimark. Do not stay with the impression that Omnimark is a very restricted language. It is, in fact, a very powerful language for text processing or for markup language processing. But, to stay with Perl because you already know it is a sufficient and reasonable reason. However, do not reduce the importance of a language without any previous sufficient homework. It's better to say that you are more comfortable with PURL than with Omnimark because you do not know the latter. But please, do not make these kind of inferences too quickly. Cheers Didier PH Martin ---------------------------------------------- Email: martind@xxxxxxxxxxxxx Conferences: Web Chicago(http://www.mfweb.com) XML Europe (http://www.gca.org) Book: XML Professional (http://www.wrox.com) column: Style Matters (http://www.xml.com) Products: http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSLT vs Omnimark, Paul Tchistopolskii | Thread | Re: XSLT vs Omnimark, Paul Tchistopolskii |
Re: XSLT-Machine in Perl?, Kai Ritterbusch | Date | RE: XSL stylesheet for printing XHT, Richard Lander |
Month |