A Community Update
June 11, 2003
In the most recent installment of this column, "The Architecture of Service", I explored the W3C's Web Services Architecture Working Group. I did so, on the one hand, because I was finding the maze of web service standards and organizations confusing; and, on the other, because I assume that my sense of what is clear and what is confusing is roughly representative of the average XML developer's sense. While I may be right or wrong about my place on the bell curve, it seems safe to assume that if I am having some trouble understanding some standard or some aspect of a standards organization's institutional arrangement or process, other XML.com readers have the same trouble.
I soon realized while writing that piece that I would need to spend another column looking specifically at the Web Services Architecture Working Group's main deliverable, the "Web Services Architecture" document. Alas, this is not to be that column. In the course, over the past two weeks, of relocating from Dallas, Texas, to Washington, DC, the amount of time I have had to devote to a close reading of the latest draft of Web Services Architecture has been, predictably, (but, in fact, unpredicted) very limited. So, in what follows, I review some of the more notable threads of conversation which have been occurring on XML-DEV. In the next XML-Deviant I'll offer some thoughts of the state of WS-Arch.
RELAX NG's W3C Prospects
As XML-DEV members reported back in early May, the adoption rate of RELAX NG in W3C projects seems to be increasing. I'm a fan of RELAX NG, so I take this as good news. Among the signs of RELAX NG's success within the W3C, XML-DEV members mentioned a schema for XHTML 2.0, the possibility of the SVG WG using RELAX NG, WSDL 1.2, XML Signature, and a RELAX NG schema in the RDF Syntax document. Norm Walsh suggested that at least one of RELAX NG's advantages vis-a-vis W3C XML Schema is that "relaxing the content model ambiguity rules makes building schemas for document-oriented schemas really pleasant in RELAX NG."
For the observer of technology standards organizations, these developments make the interplay of W3C and OASIS technologies, standards, and supporters more interesting. Someone will write a fairly interesting dissertation about all of this, probably sooner than later.
W3C Resistance to External Criticism?
Not entirely unrelated to the previous issue, this one is an amalgam of several threads of XML-DEV conversation. Uche Ogbuji made some strong claims in this regard:
Why should anyone spend time reading broken W3C specs and responding to the official lists, when some WG members (not all) seem so clearly bent on cynical response to straightforward criticism? What makes anyone think that the WGs will not just dismiss anything they disagree with with a flippant "I see no technical content in that comment"? Some say "the W3C won't let them". I am skeptical of this claim, and though I admit that I may be wrong in that skepticism, experience on this list does not suggest to me that I should make the effort to find out.
Mike Champion offered a specific counter-example: the degree to which advocates of REST were able to insist upon changes to SOAP 1.2, particularly with regard to safe HTTP bindings, caused the XML Protocol WG no little bit of hardship. Of course this example is slightly biased, given that the TAG is full of serious REST advocates and wields a considerable amount of institutional power within the W3C.
I have repeatedly over the past few years talked with people who think that the W3C -- in the guise both of some of its permanent staff and members of some of its working groups -- is unhelpfully resistant to criticism from outside the institution. There is, of course, some analytic truth to this claim. Every social institution is, to some degree or other, resistant to external criticism. But W3C critics often charge it with an inordinately high resistance
This criticism is of a piece with one which I have raised publicly, that is, the tendency of the W3C to grab the most generic names for its standards. In recent conversations with people close to several W3C working groups I have come to see that these two criticisms are also of a piece with a third: the W3C's unwillingness to standardize integration frameworks and, concomitantly, to insist that XML is the only sane basis for doing information integration.
There is no magic bullet. Taken as a whole, the W3C is not completely immune to external criticism, but the degree to which one finds it more or less not interested in seriously engaging external criticism is largely a function of which working groups one deals with. In general, the degree to which a W3C WG is willing to engage seriously with external criticism is related to how many very large corporate interests are at stake in the technology, and the degree to which that external criticism is seen by those corporate interests to threaten or otherwise delay the realization of some market advantage.
This might explain why, for example, RDF and other Semantic Web-related working groups seem willing to engage external criticism, and also why many XML developers feel that W3C XML Schema was shoved down their still-protesting throats. The W3C is certainly not monolithic in this, as in other regards. It must also be said, once again, that the XML developer community cannot do without some institution roughly like the W3C; but the converse is also true: the W3C (or some institution roughly like it) cannot do without some community roughly like the present XML developer community. Champion makes a similar point in his response to Ogbuji:
The other reason that people should "spend time reading broken W3C specs" is that few of us really have the luxury of ignoring the downstream implications of a spec that is widely supported by the major players. Whether or not one considers namespaces or XSDL types "broken", they've created considerable challenges for almost everyone, and perhaps some of these could have been avoided if more people "laid down in the road" and demanded more implementation and interoperability experience before these specs were made into Recommendations.
YAML: It's Alive!
I wrote a feature article about YAML for XML.com last year: "Look Ma, No Tags". I described YAML in that article as "a processing model and a wiki-markup-esque way to represent relatively arbitrary, high-level language data structures." Simon St. Laurent recently reintroduced YAML to XML-DEV, resulting in an interesting cluster of conversations.
YAML offers an interesting alternative for data serialization projects. More circumspectly, it may offer an alternative, depending on how much of the XML machinery you really need. YAML isn't a full-spectrum alternative as it lacks most, if not all of the real world infrastructure which surrounds XML: training and educational materials, ubiquitous programming language support, multiple parsing, querying, and storage models and implementations, an army of trained practitioners, and so on. The YAML folks would rejoin that XML needs all of that infrastructure because of its complexity, which YAML does without.
Also in XML-Deviant |
|
The mention of YAML was enough to send many XML-DEV participants off into another (fairly dull) discussion of the documents versus data perspective. That conversation didn't yield much new except for Micah Dubinko's half-serious suggestion that there should be a YAML syntax for RDF, which led Dubinko himself to suggest a CSS syntax for RDF, specifically as a way of integrating RDF and XHTML. We may be hearing more about approaches like this in the future.
I'm more interested in updating the XML.com readership about YAML, which, while not being markup, deserves a place in the toolkit of most XML programmers. As St. Laurent said, "YAML seems like a great experiment ... offering people who care primarily about the data a chance to work with the benefits of a textual format in a context that's still general but attempts to solve a lot smaller problem set."
Anyone who's interested in playing around with YAML for data serialization tasks should download Syck, a YAML library with bindings for Ruby, Python, PHP, and OCaml -- such a perversely strange mix of languages that one can only expect there to be more soon!