Notes from Don Box's XML 2002 Keynote

There is a high cost imposed on vendors by constantly evolving standards. It is hard to imagine how a small vendor can participate in the XML Web Services world which already has a sizable amount of standards when the standards are constantly changing and being updated. Large vendors like Microsoft also suffer from this because they have to deal with ship cycles and sometimes end up shipping pre-standards like XSL Pattern and XSL or XDR just so as to ship within reasonable schedules.

This has bothered me a lot about since I started working in the XML space on W3C technologies. It seems like just as you finally figure out the technology and get the bugs out of your product the W3C releases a new product. It is interesting to me to note that if current schedules are to be believed, by the time Office 11 ships with XML 1.0, XSD 1.0 and XSLT 1.0 support in a number of its products there will be XML 1.1, XSD 1.1, and XSLT 2.0 respectively. Even within the W3C it is hard to keep things straight. XQuery currently depends on XSD 1.0 but given current schedules it is likely that XQuery 1.0 will ship at about the same time XSD 1.1 will be done. It's hard enough keeping on top of the current family of specs let alone the myriad interactions that will occur once different generations of this specs exist in the wild. The same thing also rears it's head in the XML Web Services space which happens to have a lot more specs than just the core XML technologies.

There are two main conflicting camps in the Web Services world. The REST/Web architecture camp and the RPC/Enterprise architecture camp. There are zealots for both camps and Don used to be a zealot on one side but now realizes that both sides have merit and they should strive to make them both happy. At Microsoft we have millions of Visual Basic programmers as customers and we have to make Web Services work for them by allowing them to build distributed applications in a declarative manner.

Both W3C XML Schema (XSD) and WSDL have extensibility hooks such as xs:appinfo in XSD which are underutilized by the first generation of Web Services implementations which failed to expose them. These extensibility hooks could be used to add declarative features to Web Services. They (I'm not sure if this means the Microsoft XML Web Services team or a standards body) are in the process of enabling declarative hooks for Web Services which should ship in a few months. There are currently holes in WSDL in that it doesn't capture rich metadata like order of operations or security constraints just parameters and return values. This should be recified in time.

SOAP/WSDL/UDDI is the Holy Trinity of Web Services. In fact some people think of it as a single acronym. SOAP is widely deployed. People have finally started figuring WSDL out. UDDI however is not widely deployed. UDDI is a good idea but is hamstrung with a horrible syntax that only a mother could love (Reminds me of various comments about RDF/XML). They have made some changes in UDDI 3.0 that should fix the most troublesome areas. Next year should be the make or break year for UDDI. Either it gets widely deployed or is consigned to irrelevance. The primary UDDI scenario which used to be sold used to involve use cases like buyers figuring out all the pencil sellers in an area from some UDDI clound in the sky. This is a minor scenario. The true utility of UDDI will manofest itself within the enterprise on intranets for discovering services available on the local/private network.

Programming languages need to evolve. XML and Web Services bring accessing data in the forefront of programmers lives. Previous attempts to commingle data access and programming like SQLJ and embedded SQL are unsatisfactory because programmers have to keep shifting paradigms from relational/declarative to OO/procedural.

I completely agree with this and Don's message is reminiscent of similar thoughts from Adam Bosworth who used to run the team I currently work for. XML is becoming the lingua franca for data interchange in the same way ASCII text has been for a long time. Users of Microsoft technologies can look forward to their documents being XML via Office 11, their relational database being viewed as an XML data source (I was demoing XQuery over SQL Server at XML 2002), and the data coming over the wire as XML via Web Services. It doesn't make sense for there to be an impedence mismatch between the mechanism for processing all this XML data and the data itself. Some people have ideas about merging XML processing functionality into conventional programming languages in somewhat the same manner as text processing is welded strongly into Perl. One such proposal is Xtatic which I personally disliked. Others like Daniela Florescu believe XQuery is the language to make this happen and may replace Java & SQL in some cases

There will be no XML Web Services killer app. MapPoint.NET is nice but it isn't the point of XML Web Services nor is it the XML Web Services killer app. The goal of XML Web Services is to be ubiqitous. (I agree, no one talks about HTTP killer apps because it is every where and HTTP itself is the killer app. XML Web Services should strive to be the same way). If XML Web Services is still a buzzword in 5 years with conferences and glossy magazines being published in its honor then it would have been a failure. Using XML Web Services should be transparent to programmers and users alike. Programmers shouldn't have to make explicit decisions about using or taking advantage of XML Web Services because it would just happen transparently.

The last bit seems more like an echo of the integration of programming languages theme but here I find it more questionable. It's one thing to suggest adding native support of XML to programming languages and quite another to suggest ignoring the eight fallacies of distributed computing at the programming language level. In retrospect, this aspect of Don's speech was one I considered questionable but never ended up bringing up with him even though we had dinner that evening. Given that I know he reads my diary I'm sure he'll clarify what he meant soon enough.

#

 

Categories: