[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XSLT vs Omnimark

Subject: RE: XSLT vs Omnimark
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sun, 5 Mar 2000 11:20:15 -0500
omnimark saxon preview
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.