[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSLT vs Omnimark
Hi Didier , > Paul said: > XSLT is absolutely different concept. I don't understand how those 2 things > could be compared. We are not comparing XSLT with perl, right ? > > Didier replies: > Just to fix the clocks :-) > > A) XSLT is a rule based language. A document tree is created, then pattern > are matched on this tree and template's content are included in the result > tree right? > B) Omnimark is a rule based language. But I am not so sure if it builds a > document tree. 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 ;-) > > XSLT template: > <xsl:template match="element"> > ...your stuff here.... > </xsl:template> > > omnimark rule: > element "element" > ... put your stuff here.... > > In both cases the rule is fired when the rule's pattern is matched with the > document's corresponding node. > > So Paul, Omnimark is nearer to XSLT concepts than PERL. To compare PERL with > XSLT is like comparing potatoes with oranges but comparing Omnimark to XSLT > is like comparing two kinds of oranges. .... 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. 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. 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'. I agree that having one more kind of patterns ( patterns for XML tags ) and firing events on letters could be seen as a serious concepts. Now there is a question. When working on something with 'patterns' - it is DOM-alike. When processing the same 'something' with 'events' this is SAX-alike. The trick is to find a nice way to balance SAX' efficiency with DOM's ease of use. ( mixing push / pull ). Perl has some more-or-less convinient and more-or-less reasonable ways to do that. If taking into account saxon:preview - it looks that XSLT tries to get there. The 'lookahead' thing I saw in Omnimark tell me that Omnimark is 'pure-streamable'. I don't thing 'pure-streamable' tool is useful. Could you, please educate me me - is there any support of 'DOM-ish' processing in Omnimark ? What is the largest possible accumulated chunk? Word? Line ? Element ? After you explained how it is possible to look on Omnimark, it think Omnimark could be considered 'XSLT-alike technology'. Kind of 'streaming XSLT, attempt 1', right? Rgds.Paul. PS. BTW. .... It seems Omnimark could be easeily written in Perl , but Perl hardly could be written in Omnimark. .... When I looked at the samples I found that Omnimark is very much like Perl in a sense that it is very eclectic and strange mix of many things, trying to solve many problems at once. .... What Omnimark in fact did was placing XML parser on the level of regular expressions, but not having XML parser to be 'standalone tokenizer', right? The same placement could be done in perl. I mean that one can get 'absoluetely event-driven + taking into account < and >" easily written in Perl. Yes, maybe is is good to get it in the language, but ... I don't think the advantage is worth learing new language ( and dropping perl ;-) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|