Related link: http://www.adtmag.com/article.asp?id=10286
“Perspective on XML: Be humble, not imperial” was directly inspired by conversation with Simon St.Laurent about whether RDF is separable from design hubris (and how such hubris intersects XML). Today I found an interesting juxtaposition of premise in Sean McGrath’s “Inefficiency revisited“. One thing I seem to share with so many of my colleagues in the XML world is a wary attitude towards traditional data modeling practices. It’s an attitude that has also informed my thinking in related articles pondering data supermodels,
coupling of distributed systems,
OO encapsulation, and the like.
Some of us see XML as a bit of a refuge from established schools of data modeling. OO and Unified Process in my case, E-R and other relational based modeling in others’. Some just came from document-centric backgrounds where such extremely rationalized data modeling was not the mainstay. In my case, interest in XML was part of a general interest in data modeling as a vehicle for human expression rather than for robotic simulation of the real world.
I learned a lot in my own journey along this path from folks such as Sean McGrath, Simon St.Laurent, and Walter Perry. Walter in particular is worth a note. He doesn’t publish many articles, nor do I think he posts much to XML-DEV any more, but you would do well to look up some of his older postings on that forum, especially some of his debates with John Cowan (who is also always worth a read). He has a very interesting perspective on the role of XML in data sharing, and though it takes a bit of close reading to ravel the important conclusions from his expansive essays, I’ve found the effort rewarding.
I think a lot of the stress in the XML community centered on the fulcra of XQuery, SOAPish Web services and W3C XML Schema represents a split between what I’ve called the Bohemians and the Gentry. The Bohemians see in XML some escape from deep-rooted philosophies elsewhere that they feel lead to software boxed in by overly sophisticated (and imperial) design, and thus doomed to integration woes and expensive maintenance. The Gentry think that imposing the rigors they bring from other spheres of data modeling upon XML is the only way to bring order to XML’s strange arcadia of uneven structure and untyped chunks of data.
It’s easy to over-sell the “agile” ethos. Even though I can agree with XP folks that Big Design up Front (BDUF) too often leads to death-march projects that never end up truly meeting the customer’s needs, the Engineer’s training in me can’t accept that this is an inherent flaw in the idea of design before implementation, but rather a sign that popular design mechanisms are just not good enough to support software development needs. I find XML much better aligned with the agile world view, but only insofar as it brings a perspective to design that still needs proving and codification, and that once established will still demand the highest standards of professionalism from its practitioners.
Has using XML changed your general approach to data design and modeling in any way?
Curmudgeon fusses out loud
And then there are software developers, like myself, who place XML in the same category as ASCII & Base 64 Encoding and wonder how XML can have such profound influence on anyone's thinking. (However in true Canadian fashion I will try to provide balance to my curmudgeonly comment by saying I have often profited by reading Uche's work.)
Curmudgeon fusses out loud
Heh. I understand the perspective. XML as a data format is indeed not very interesting. However, if XML happens to be the first formalization of semi-structured data management you came across, it can have a profound influence. Not because of the mechanics of right-angle-bracket/left-angle-bracket/text, but rather because of the overall model of strict-text semi-structured data. This is not the same insight as flat text formats alone because XML adds standardized tools for formalization of fundamental structure. This is not the same insight as hierarchical DBMS alone because XML adds the discipline (yes "discipline") of forcing textual representation, and thus centering data more on human expression than most perfunctionarily hierarchical systems. Some people did come to such insight by way of HTML/Web, but I find that remarkable because I was never able to look beyond HTML's narrow-minded vocabulary and tag-soup culture. It does make sense that a lot of people came to such insight through SGML, which did have all the expressive mechanisms we're currently reinventing for XML (and in some cases more).
Thanks for the note. I feel another blog coming up...
Curmudgeon fusses out loud
They get revinvented for the same reasons they were invented: occasional needs. The standards mindset is that all bits for every need and that was the mindset XML set out to break down. When you need a bit, should you invent it, reinvent it, or borrow it?
The issue is not having the extra bits; it is some higher power that attempts to force you to use them when you know or think you know you don't need them.
SGML was too tightly knitted together as a single system. XML is a tight syntax and a loose confederation of application languages. That is what an ethos of rough code and running consensus produces. (Yes, I know that is transposed from the original.)