xsl-list
[Top] [All Lists]

Re: [xsl] ATTRIBUTE ORDER

2006-06-03 04:00:38
It was be tough = It *would* be tough :)

On 6/3/06, M. David Peterson <xmlhacker(_at_)gmail(_dot_)com> wrote:
Hey Wendell, :)

On 6/2/06, Wendell Piez <wapiez(_at_)mulberrytech(_dot_)com> 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
Lisp.

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

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
instead

>>  "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:D/>

M. David Peterson
http://www.xsltblog.com/



--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>