Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What are the practical, negative consequences ofthinking t
 The story I tell these days is that XML started out as a brilliant effort to simplify SGML, a tool that was built for working with documents. In that context the element/attribute/content/attribute value distinctions at least usually make sense, and the verbosity of markup is a reasonable tradeoff in a flow of text meant for (at least occasional) human eyes. Unfortunately, XML's appearance on the scene reminded developers of the insanely terrible data exchange systems they'd previously built, and seemed to offer a different path from past disasters. For smallish quantities of data, the verbosity tradeoff wasn't bad, and having a format more non-programming humans could comprehend was helpful. XML was a mediocre solution for data that was slightly better than the awful that came previously. Unfortunately that "slightly better" meant that developers all wanted to pile in with the awful to make it familiar. XLink vanished from the agenda, replaced by ever more intricate schema, transformation, and query languages. Programmers frequently found that the information modeling approaches of the markup document community didn't apply to their work, and often set off to create even worse formats that happened to talk with code they already had. (Yes, Apple. I'm talking about your plists.) After a while, many developers realized that this XML thing really wasn't for them. I was delighted when JSON appeared, not because it was a perfect solution but because it hit a different point of mediocrity that leaned more toward what programmers really wanted, and could conceivably let XML do the things which XML's markup approach fits. (I am somewhat amused that functional programming approaches that boggled people's minds in XSLT 1.0 are suddenly kind of hot, and in the JavaScript world that largely happened through the evangelism of JSON's creator, but the approaches work well even when the data formats change.) Unfortunately, I think that freedom came too late. Developers' image of XML as a verbose overly complicated mediocrity had overwhelmed the initial news of XML as simplification. Browser vendors turned against XML partly because of the growing complexity, but largely because it turned out that users didn't love the well-formedness expectations the browser vendors had asked for in the first place. HTML5 demolished it, and Web Components may finally provide the extensibility XML proponents discussed two decades ago, if they ever get traction. ("It's too much like XML" is a common way of dismissing them....) XML still works beautifully, if you apply it to the experience from which it emerged: documents. It works far better if you can forget the weight loaded onto it by a decade and a half of developers trying to make it fit a space it was never going to handle gracefully. XML can work for some lightweight data storage and messaging, but somehow that rarely stays "light". So yes, there are practical negative consequences of thinking that attributes are metadata, but they tend to be more the result of the practical negative consequences of thinking that markup is a great place to store structured data. Thanks, Simon On 2/16/2017 8:59 AM, Thomas Passin wrote: I still see using XML for little transient Domain Specific Language (DSL) type jobs. That's largely because you can transform the data with xslt. Now that json is coming to xslt (with version 3.0), maybe I'll feel like starting to use json instead... we'll have to wait and see. 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|
|||||||||
