[
Lists Home |
Date Index |
Thread Index
]
Personally, I don't think the success of XSLT is in doubt,
maybe the popularity given the lack of some features.
Still, WASD. A spec is driven by user requirements
to design a system. A standard is driven by working
common practice that can become a control.
We do it to ourselves because we desire power. Then
when the complaints start, we squeal "STANDARD" or
some other magic word, but the complaints just keep coming.
I was asking in the context of complex systems theory
if top down or bottom up designs made any difference to getting
his set of "nuts and bolts" into the design. You seem to
suggest that user-driving the requirements might help. I
don't know if that equates to "swarm intelligence" or not.
I know that if that is done, those breezy requirements that
typify a web project since XML won't be adequate.
Grass roots designs can succeed based on momentum
when from a perspective of efficiency or elegance, they are
awful. We say, who cares because they are used. That is
buy in followed by lock in. It has nothing to do with
the design being broken; just popular. This part of
the computer design is NOT science: it is the art of
war, politics, and entertainment: really, sales. That
is where the "magic" words enter the descriptions.
Systems engage; controls emerge.
len
-----Original Message-----
From: Michael Kay [mailto:michael.h.kay@ntlworld.com]
> "the following article by Tom Moertl is a succint summary of the
> issues with XSLT that I've heard developers voice and that
> I've had myself"
>
> http://www.kuro5hin.org/story/2002/1/13/223854/606
>
> which summarizes:
>
> "If there is a lesson to be learned, it's that
> domain-specific language design is hard. The XSLT designers
> created a language that lacked much of the nuts-and-bolts
> functionality necessary to make it genuinely suited for its
> intended purpose. While the designers doubtless left this
> functionality out of the spec on the grounds that XSLT isn't
> intended to be a general-purpose programming language, they
> failed to realize that even simple document transformations
> often require a little nuts-and-bolts programming. Leaving
> out the nuts and bolts made XSLT a broken language.
>
Actually, XSLT 1.0 has been extremely successful. It has its limitations but
to describe it as "broken" is absurd: it does lots of things well but it
doesn't try to do everything. The things that were left out of 1.0 (for
example, regular expression handling) were left out deliberately, to reduce
the risk of getting them wrong. The problems faced by users are not due to
any failure by the designers of XSLT 1.0, but to our subsequent failure to
ship a timely upgrade that responded to the early feedback. We can go into
all kinds of analysis to see why that happened, but the bottom line is
probably that the standards process is not sufficiently user-driven.
|
