[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Re: XML and Complex Systems (was Re: Re: An Arch

• To: "'michael.h.kay@n...'" <michael.h.kay@n...>, xml-dev@l...
• Subject: RE: Re: XML and Complex Systems (was Re: Re: An Architecture for Limericks)
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Wed, 16 Jan 2002 08:52:14 -0600

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@n...]

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

• Follow-Ups:
  • RE: Re: XML and Complex Systems (was Re: Re: An Architecture for Limericks)
    • From: Sean McGrath <sean.mcgrath@p...>

• Prev by Date: Problem passing parameter to XSL thru JSP
• Next by Date: RE: Xml is _not_ self describing
• Previous by thread: Re: Re: XML and Complex Systems (was Re: Re: An Architecture for Limericks)
• Next by thread: RE: Re: XML and Complex Systems (was Re: Re: An Architecture for Limericks)
• Index(es):
  • Date
  • Thread