RE: Application Design

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Or they pick one customer to model and provincialize the product. 

It is key to note that often we learn to the boundary of other knowledge 
and then try to work from that.    True for hackers, spec writers, 
and so forth.   The problem is the broadcast media we are working 
with and the religious "must defer to belong" attitude some bring 
to solving problems.   Too much of the MIT thinking is based on 
the notion of "one system over all".  That basic immaturity 
has affected almost everything from browser and protocol design 
to our economies.   We have to solve the problems of compliance 
and competition.    A specification is one one hand a market 
enhancer and may incubate technology; turning it into a 
standard too quickly or insisting it is that when it is still 
just a wet idea is guaranteed to be a brake on innovation and 
a crutch in the market.

XSL is quite handy for many things XML.  XML itself isn't always 
the best solution.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Francis Norton [mailto:francis@redrice.com]
Sent: Tuesday, August 14, 2001 4:59 AM
To: Bullard, Claude L (Len); xml-dev
Subject: Re: Application Design


Hi Len,

"Bullard, Claude L (Len)" wrote:
> 
> Unfortunately, they do.  Usually I see this
> where to-the-metal programmers learn
> just enough to connect the new
> to what they already know.   

That's the way I've seen it happen. The more competent the programmer is
the more likely they are to fall into this trap - I think because the S
stands for stylesheet they assume that anything associated with it is
slow and ugly. (And that's why I try to remember to use xsl:transform
instead of xsl:stylesheet, pedantic as it may be.)

> XPath isn't trivial to learn
> on the first pass, and if they practice solo Extreme,
                                          ^^^^^^^^^^^^
Yes - boring old consultants do requirements and use cases and test
plans (which don't actually hurt that much if you got the use cases
right) but there is always a temptation for good coders to just hack it,
and it's even stronger for ace coders. But if it turns out they didn't
understand the user requirement in the first place, or they hand it over
to another coder - well, it's hubris for hackers, in the original sense
of both words ...