Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hi,
At 02:38 PM 7/8/2008, you wrote: On Jul 8, 2008, at 6:52 AM, Wendell Piez wrote: I think Mike pretty well described it, if you retrace the thread. To reiterate in more general terms, requirements for engineering processing pipelines are frequently open-ended or convoluted, or both. Hence it is common to find sooner or later that you need to do things respecting dependencies in your environment (regarding presence, absence or mutability of resources, or order of execution) which XSLT, which likes to work within a closed world, has to be pushed to accommodate. For example, recently we've seen several threads regarding how to get output serialized in particular ways. This is a common set of requirements but one which XSLT doesn't address naturally (its basic position being that XML is XML), and processors vary considerably in what extra help they give in this regard. In a fully mature system, we'd have fast, easily configured components to handle serialization, and we might never call on features in XSLT at all. Lacking such components, and not having the time or expertise to develop them ourselves, many of us find ourselves using XSLT. It works, but it comes at a price. Addressing serialization requirements inside transformations can hinder portability; in the worst case it can even mess with the data in ways expensive and time-consuming to remedy. Keep in mind that systems tend to go wrong when they're doing not what they're designed to do, but what they were built to do while they were being designed to do something else. Now it could be that robustness and scalability aren't problems for you, and you don't have special requirements at the edges. That's fine; unlike many readers of this list, I frequently work in prototyping mode, and can get away with quick and dirty. But being sometimes ready to do things in a way that other developers recommend against shouldn't (I hope) make me blase about why they recommend against it. On the contrary: I ought to be even more alert to the tipping point where an approach like this becomes more trouble than it's worth. (Mike did indicate that he's learned by experience, which if it's any comfort suggests that someone as smart and knowledgeable as he is did once consider the approach to be reasonable. Since then, apparently he's gone beyond that. :-) I am, BTW, having no problems using XSLT this way. Generally I don't either. But depending on where you're going, you might have a concern about tomorrow as well as today. The advice you get on this list is free: take it for what it's worth. :-) Cheers, Wendell
|
