Hi,
At 02:38 PM 7/8/2008, you wrote:
On Jul 8, 2008, at 6:52 AM, Wendell Piez wrote:
... I don't disagree with other opinions given in this thread
relating to the robustness and scalability of using XSLT for this
sort of thing.
Okay, it is exactly this kind of statement that I am trying to get a
handle on. :-) What are the issues?
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
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================