[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: Sat, 4 Mar 2000 15:05:02 -0500
omnimark vs xslt
Hi Paul,

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
b) DSSSL
c) XSLT
e) Omnimark

Paul said:
.... You mean, there is something strange with Omnimark's ad?
They are selling it as a 'better perl',  that means in your terminology they
are
comparing oranges with potatoes.

Didier replies:
yes you are right this is what they are doing. Their real competitor is XSLT
not PERL. But the marketing guys at Omnimark are quite slow on the switch
:-))

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

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 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>"

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/>

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. Probably the next generation written in C++ an
more optimized than today's prototypes will bring sane competition and for
us, at least, tools to transform our XML documents so that if I type in a
browser's address box
http:// my site.com/folder/myxmldoc.xml I get either an HTML doc if I am
using a non XML aware browser and an XML document+xslt if I am using an XML
aware user agent.

Does anyone knows any site allowing that today?

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.