Re: [xsl] ATTRIBUTE ORDER2006-06-03 04:00:38It 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> --~--
|
|