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


From: "M. David Peterson" <xmlhacker@xxxxxxxxx>
Date: Sat, 3 Jun 2006 04:59:10 -0600
c attribute
Hey Wendell, :)

On 6/2/06, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:

>Of course, this kind of information can't be overlooked, as you simply >have no idea who might be running your code and with what processor at any >point in the future....

No, you have no idea ... except when you do.

A funny, but OH SO TRUE statement :)

 I have any number of
stylesheets that will never run anywhere except on my own system, in
a processor of my choice. I also write (and deliver to clients)
stylesheets that are warranted to "run the same" on X version of Y
processor (due to their use of extension functions or whatever).
These cases I think are safely within the zone.

It was be tough to argue such a position... nor would I want to. It's spot on.

In short, it's true that collation order creates an edge case for the
sort-your-attributes solution to the attribute-ordering problem. On
the other hand, one is not always looking at an edge case.

Yup :)

Yet one of the reasons this list is a useful resource is that we're
very careful, even sometimes to a fault, about edge cases.

I wouldn't call this a fault. Rarely will you find people who can't recognize that there's a need for a caution in a community based setting where there are SO MANY processor implementations. Off hand, I can't think of one single language that has as much support by as many independent companies (and therefore independently developed implementations) as does XSLT 1.0 + EXSLT 0.x (is that a fair version number estimate to place on the current state of support for EXSLT in the various processors?). It's a phenomenon that I doubt will EVER be paralleled again.

Errr, wait.  I guess there's this little language called Lisp ;) that
probably has as many processors.  Of course XSLT is directly rooted to
DSSSL, which for all intents and purposes has its roots directly in

The difference, in my opinion, is that for the most part the XSLT
processors ALL conform to a spec.  The Lisp processors support their
own variation of either Common Lisp, or variations such as Scheme,
which if not mistaken, began several years before the effort to
standardize Lisp with Common Lisp.

This particular area is a little fuzzy for me. Anybody care to clarify?

Either way, the fact remains... XSLT 1.0 + EXSLT 0.x (see above
question) I believe stands alone as the single most successful
language in terms of processor support that, for the most part, all do
a pretty bang up job of sticking to the 1.0 spec, filling in the
blanks with a few proprietary solution (node-set, err, nodeset, err
NodeSet, err, whatever ;)) as necessary, or bringing even more power
to the table by building against another (son to be?) standard in
EXSLT (ahh.... node-set(), etc... :) to add some fairly powerful
feature extensions.  Of course, then you FXSL which adds even more
power using only XSLT 1.0 and (now) XSLT 2.0, but I digress (as usual

So back to > "I wouldn't call this a fault." < This is DEFINITELY one
of the most important "features" of this list.  As mentioned, people
are smart enough to figure the rest out for themselves (e.g. Do I use
this proprietary solution or not?), so think we can safely state that
one of the primary reasons this list has been and continues to be so
successful is that, for the most part, folks have agreed to take a
firm stance at promoting cross processor solutions as often as
possible, and adding proprietary extensions to the mix with proper

I don't think there could possibly be a better approach, so if I were
to disagree with ANY of your overall statement, it would be that this
isn't a fault, and instead the reason that XSL-List is such a reliable
source of information in the first place.

I could
have qualified my suggestion further (actually I did remember the
caveat, but was in haste as I wrote :-). But then we wouldn't have
Mike's (and David's) correction to think about, or M. David's
recommendation to hedge the hedge with comments.

The XSLT 2.0 solution, select="(@mike, @davidc, @dimitre)", works
great -- as long as you know who your attributes are ahead of time.
(Which the OP did, IIRC. But I don't think he was using 2.0, and
personally haven't come to the point where I'm recommending 2.0
solutions to 1.0 problems except in dramatic cases.)

There is also a TON more granularity as far as processing, sorting, collating, etc... in XSLT 2.0, so even if you don't know the attributes ahead of time, while you definitely need to spend the time studying, theres a TON more power here that allows for a MUCH more generic approach to processing if this is your desire. I should note: I've been studing XSLT 2.0 pretty solid for over 2 years now and still feel like I've only scratched the surface... but thats not a bad thing because I can still use my XSLT 1.0 knowledge, and except for a few edge cases, expect for it to work on an XSLT 2.0 processor as expected without using any sort of XSLT 1.0 compatibility mode.

There are some pieces of XSLT 2.0 that some of us may never find need
to use.  But then again, there are a TON of developers out there
coming from the statically typed languages who need these features to
make the cross-over.  Not from a "Oh, I get it now" stand point and

"Oh good... I can extend my existing C++, Java, C#, etc... skill
set and code base and, using an XSLT 2.0 Schema Aware processor such
as Saxon SA, be enabled to both provide understanding as to what my
current code base is all about (with help of an XML Schema) to then
extend this even further by adding a layer of dynamic code generation
and/or validation via the tried and proven template-based
transformations approach such that I can gain the best of both
worlds." <<

To put it another way, XSLT 2.0 is the binding mechanisms that brings
ALL OF THE POWER from both sides of the equation (Dynamic XSLT <=>
Statically-typed languages) together into one EXTREMELY powerful
language that embraces a HUGE base of developers and a MASSIVE code
base that up until now was fairly isolated from the wonderful world of
dynamic languages.

This is pretty important stuff, and not enough credit can be given to
this list, and in particular, Dr. Michael Kay for understanding this,
and bringing this important spec into existence.

To all of you who have played a part in all of the above mentioned
specs, processors, and extensions,

Thanks! :D


M. David Peterson

Current Thread


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.
First Name
Last Name
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.