RE: combining malfunctioning, evil adult as XML with Elliot Ru
Humans are "less than optimal" in a huge range of habitats. Yet we're comfortable and effective in almost any environment. Evolution is funny that way--animals and plants have a tendency to occupy, and thrive in, unexpected niches. We used to live in trees right? Surely we were "less than optimal" for the plains and wide open spaces. Or maybe not. Don't we need to be comfortable with change? Getting stuck in a niche is the quickest route to extinction if conditions ever change. And conditions always change--that's entropy for you. I actually agree with Eric too, from what I can read and understand, but I just think that the balance between specialized and general purpose is one of the most fluid and interesting in IT, and not something that can be controlled. It's all about the balance between available resources against current problems. When networks are [expletive deleted] cheap, for example, a whole range of possibilities present themselves. When networks are expensive--different problems need to be solved. Its like centralization and distributedness--both have a place in the world, and some of the most exciting developments happen when they converge (Linux on the mainframe, for example). Recently someone on this list gently roasted network hardware accelerator vendors for getting into the XML game. But these vendors are just trying to address a problem --that is, the verbosity of textual encoding. This to me seems a sensible attempt to solve a problem. What's the alternative? Demand that all network traffic is binary encoded? Ban XML from corporate networks? The "good enough" surely defines success in IT and the world at large. From where I am standing, with neither a programmer or markup prejudice, it seems like XML is "good enough" for a wide range of applications and use cases. I see all sorts of communities getting excited by XML for this reason. Might XML get "bastardized" or even "hybridized"? sure. Is binary more appropriate in some use cases? Sure. Will it coexist with markup? Sure. But people have to make their own mistakes, have to discover what technologies are most appropriate in which niches. And if the technology has to be forced to suit the niche, and creates value in the process, well then so be it. And if conditions change to make a technology appropriate in a way it didn't use to be, then that's cool too. Likesay, barbary macaque monkeys in Gibraltar. The complaints are good. That is human nature. Conflict leads to creativity and problem solving. The "meaning" of XML is surely to be found in how it is used, not in some "essence of markup" Hey I just got another post from Mike Champion that says something similar WAY WAY WAY MORE more effectively than I have done! Maybe he will get the brunt of the flame.... ;-) ------------------------------------ Excerpt from Mike post below ERH has a thought provoking comment on his weblog today http://www.ibiblio.org/xml/ It's interesting that the Web Services community has managed to alienate three different communities for three different reasons that all derive from not understanding or accepting the basic principles of the technologies they're building on. They're either geniuses or idiots. My money's on idiots, but time will tell." ------------------------------------------------------- On the "XML community" critique, the way I see it is that the Web services people are pushing the XML envelope in ways it was not pushed before, and have found it wanting: Things like entity references play hell with efficient buffer management in high-performance parsers; XML 1.x is not composable as specified, which makes the full spec unusable for a header- extension model such as SOAP offers, and so on. (See the response by the XMLP WG to this issue on www-tag a month ago for details). It's not at all clear what the best way forward is -- forking, profiling, deprecating for XML 2.x -- but I personally have little patience with the argument that the "fundamental design of XML" has been compromised. In fact, the fact that the SOAP community independently came up with essentially the same profile of XML that the SML-DEV folks did a few years ago ("Common XML Core") makes me even more convinced that the "fault" lies more on the XML side than the WS side. Document and Messaging XML use cases certainly share a lot, but maybe they don't share everything. I resist data-heads imposing their paradigm on XML as a whole, and I resist doc-heads insisting that data- oriented applications do it the One True XML Way. My money is on the geniuses (whichever community they're in!), simply because they're learning what actually works and are adapting in real time. I'll bet against the zeaots (in any community) who think they understand the problems of everyone by their knowledge of certain a priori principles. As offensive as I found much of Erik Naggum's post discussed earlier, I gotta love his .sig: "Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder" So, I pose the question: are the various communities who "detest" SOAP/RPC Web services acting from reason and learning from both the WS failures and the failures of their own pet theories, or are they acting from faith and blaming those who tried to apply their pet theories and found them wanting? To be honest, I see lots of adaptation to the ideas of REST and XML in the WS community, but don't see many signs of learning from the WS experiences in the REST and XML communities. Maybe I'm acting "from faith" too :-) Thoughts? -- Mike Champion
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format