[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Application Design
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: firstname.lastname@example.org, xml-dev <email@example.com>
- Date: Tue, 14 Aug 2001 08:33:15 -0500
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.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Francis Norton [mailto:firstname.lastname@example.org]
Sent: Tuesday, August 14, 2001 4:59 AM
To: Bullard, Claude L (Len); xml-dev
Subject: Re: Application Design
"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 ...