다음을 통해 공유

More on Design by Committee

  • 아티클

Michael Rys says in a comment on the previous post "I personally think
that XQuery is not bad for having been designed in a committee overall
(compared to the DOM :-))" These continuual slurs on the DOM!
Everywhere I go, even from my
closest colleagues, sniff. :-) 

Neither DOM nor XQuery are "bad"
for having been designed by committee; my point is that no rational
person would argue that they are as elegant as LINQ.  That doesn't
necessarily mean that LINQ will be more successful in the
marketplace.  My favorite comeback to the "DOM is the proverbial
camel designed by a committee trying to create a horse" is that camels
are more sturdy beasts than horses, especially if you are exploring in
the desert.  DOM is actually a remarkable sucessful spec, even
though it is not well liked by most of the users I talk with. 
Actually most of the things Anders, and Elliotte Rusty Harold (who
developed the Java-specific XOM API) don't like about DOM were features
not bugs - it is language neutral, interface oriented rather than class
oriented (it was intended for companies to use on top of their existing
HTML and XML internal data structures and object models, not to replace
them), it *is* essentially an InfoSet assembly / disassembly language
(we thought there would be competition among designers/implementers of
"convenience classes" that would live on top of the low-level DOM). The
kludgy namespace support, and general weirdness for things like entity
references, has to do with the kludginess and ugliness of the
underlying specs, IMHO, not to mention the fact that DOM Level 1 came
out before the Namespace spec was final.   The namsspace spec
was a fast-moving target in 1998 ... and if DOM had missed the IE5
(and, we thought at the time, the Netscape 5) spec freeze date, it
would have been Game Over.  I think that XLinq has a much cleaner
namespaces model, but that comes from ignoring the principal design
point for namespace prefixes - to make XML documents easier to
type. 

As for XQuery, well we will just have to see if it succeeds BECAUSE it
is such a potent gumbo of good ideas, or if it fails because some of
the chunks are too big and some of the shrimp weren't cleaned very well
:-)  I think that XQuery and XSLT will both find secure niches
because when the evening rush comes, you've gotta serve the customers
and they care more about how fast it is served up than how clean the
kitchen (or sausage factory)
is. Less metaphorically, when performance (and portability,
standards-compliance, etc.)  is critical the fine-grained control
of these standardized specs will give real advantages, especially deep
down in the infrastructure away from the people who don't have to
process large quantities of XML themselves. I personally lost most of
my interest in XQuery as a client side development language -- targeted
at people who need the power of XSLT but without forcing them to turn
their brains inside out -- once I learned about what we now call
LINQ.  My guess is that the mainstream developers that Microsoft
caters to will feel likewise.

No discussion of this subject is complete without these important links .

Comments