|
Let's keep in mind just who brung us to the dance here: Metcalfe's Law (or the network effect) -- basically, XML is highly valued because it is so widely used ... which makes it more widely used, which makes it more valuable ...
XML (the hard core that people use, not the tottering superstructure that all 2500 pages of W3C specs collectively define) is "good enough for gummint work" while being simple enough to easily use and implement. That's all ... until we factor in the network effect. Then everybody's gotta have it because everybody's gotta have it.
So what's this got to do with Edd's argument? Basically, let's be very wary of throwing out the benefits of the network effect offered by XML syntax unless we leverage an even better one. For example, the filesystem path metaphor is so powerful and widely understood that XPath hit the ground running, i.e., it leveraged the "network effect" of hierarchical filesystems that everybody understood already to describe patterns in XML hierarchies. One might argue that regular expressions have a similar benefit because they are widely understood by programmers and supported by software tools. Fair enough.
But if the value of the "little languages" is just that they are easier use and understand than XML, I part company with Edd. XML syntax may be overkill for many purposes that little languages are better suited for, but the XML grammar is getting hard-wired into people's brains, XML parsers and APIs are ubiquitous, etc. What's the value proposition for even thinking about writing a new grammar, parser, API, etc. for some task that XML is "good enough" for? Maybe XML is too verbose in a given appication (e.g., for SVG), or maybe its data model doesn't fits well (e.g. RDF), and in these cases it's pointless to "bludgeon
everything into angle brackets." But for a lot of other things, the value of being able to manipulate stylesheets, schemas, metadata, etc. with the very same conceptual and software tools as one uses on the data can outweigh the overhead of using XML.
I doubt if "XML is too hard to author in" leads to a widespread value proposition for little languages. XML is simple enough to be easily generated from about any linear or tree-like data structure, and most users want to author in a GUI environment rather than learning a new "little language" anyway.
So, I guess I see the "trees" that Edd and Kurt do (XPath, SVG, RDF) but I'm not sure that there's a "forest" out there that warrants widespread application of a little language design pattern.
|
Previous Message
