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

Re: alternating tags in a list?

Subject: Re: alternating tags in a list?
From: Guy_Murphy@xxxxxxxxxx
Date: Wed, 16 Dec 1998 09:07:00 +0000
alternating bullet list
Hi.

You seem to have surmised all my rants in one concise post. Maybe I should
just send my posts to you in batches,
and you can provide a sensible surmation.

The crucial point here is that browser manufacturers as you point out will
add the necessary functionality if the W3C
tried to deny the addition. In my mind if XSL can't replace 90% of ASP I
don't see the point in it.

A good example of the W3C trying to deny the reality of the browsers was
FRAMEs, which the W3C tried to pretend wheren't
an issue. Even in the HTML4.0 spec they're only grudgingly admitted,
actualy being added to an alternate DTD.

Does the W3C serve the industry or are we beholden to the W3C as to a liege
lord?

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 12/15/98 11:58:17 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: alternating tags in a list?





 I don't see the big deal about allowing script code to be evaluated
via XSL. If the XSL-WG isn't willing to add the neccessary features to
XSL to make it useful for most web developers, what's the point?
  You're suggesting that if XSL can't handle a particular query, that
someone post process with DOM+script. But processing nodes via DOM
in a language like Java is painful. Lots of getElementsByThisOrThat,
followed by for/while loops, following by accessor calls to
Attributes trying to perform a match.
 In other words, the irritating, non-concise, bug-probable code,
that should be handled by a nice tailor made language using
a standard matching engine. XSL could alleviate most of
this work by allowing script-coders to use a "Visitor Pattern"
where XSL visits the nodes, and the script code gets ran on
each node in the query.
  I used to think I understood what XSL was, what it was going to do
for me, but now I'm not so sure. I thought it was about style, and
rendering XML documents on the web. But apparently, that changed. Now
it seems it should be called XTL (extensible transformation language),
since now most of the talk is about transformation. But it doesn't
seem to be great for transformation either if it can't do simple
thinks like an even-odd rule.  What is it, a style language or
a transformation language? It doesn't seem to do either thing
particularly well right now.
  To top it off, there seems to be a resistence on the part of some
people to either 1) add the appropriate power to the matching language
or 2) temporarily break out to script code.  I think this is naive. It
is obvious to me that XSL lacks the power to do a lot of common web
formatting cases that is now handled by ASP code. This means there
will be a huge web developer demand for this functionality, and
commercial companies *will* add it to the language. It's not a
question of *if*, but when. Of course, there will be many
incompatibilities between these extensions, with one company
mostly dominating (likely MS) as a defacto standard, and finally,
the W3C will be forced to bite the bullet and declare the
extensions part of the standard.
-Ray









 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list






 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.