[
Lists Home |
Date Index |
Thread Index
]
dareo@microsoft.com (Dare Obasanjo) writes:
>Probably no more amazed than I by the horrible but "technically
>relational" databases that people design or horrible but "techically
>object oriented" programs that people write. That's the price you pay
>for popularity.
It's not just popularity, I'm afraid.
It's very easy to take a look at an Access database that's held together
with bubblegum and duct tape and explain how the information could be
normalized better. Justifications abound, and I'm actually glad that I
read the infamous Fabian Pascal's "SQL and Relational Basics" before I
touched an RDBMS. It's not that hard to explain the benefits, and there
are small armies of people trained in doing exactly that.
It's not as easy but it's still quite possible to take apart a sort of
but not really object-oriented program and explain what making it
object-oriented would look like, and again there's a whole literature of
explanations, from early writings on OOP to Design Patterns to the
current refactoring discussions.
In XML, we don't really have such things. I still tell people to read
Eve Maler and Jeanne El Andaloussi's book, David Megginson's
_Structuring XML Documents_ turns on lightbulbs, but for the most part
there isn't a body of rigorous markup practice that commands nearly the
same respect as the practice discussions for RDBMS and OOP.
What authority might emerge is regularly subverted by tool vendors and
people who are happy to smash objects and Infosets together, and too
many people just talk about "transfer syntax" like it's a "transfer
station" for garbage.
I still hope that best practices emerge as the hype cools and we have a
few decades to ponder the train wreck that XML has become.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
