Pushing String

Chuck Mortimore dropped me a line to draw my attention to this startling announcement (found through this post): knitting is really, really, really popular on Bloglines.

Crocheting feels pretty trivial, but somehow knitting has eluded me. Having seen two colleagues knit at a good clip (hey, I started a trend!) during last week’s Liberty Alliance meeting in Dublin, where beautiful sweaters can be seen all over the place, I’m feeling the urge once again to try learning the ways of the knitter. Now I’ve been invited to an honest-to-goodness knitting circle at work (they call the group Stitch ‘n’ Bitch :-) and I’m determined to get a lesson. I will dutifully report on my progress, or lack thereof.

Now back to feeling guilty that I haven’t designed my XML 2005 cross-stitch project yet…

The XML Core WG has come out with a draft of XLink V1.1 that focuses on two main changes: full conversion to IRI language and concepts, and making xlink:type="simple" an application-level default (a bit of sweetening that I cheered on here as an idea whose time had come). So now you would be able to just throw xlink:href on an element to make it an XLink simple link. I see they also added a RELAX NG schema example, which is a good idea.

I hadn’t looked at the XLink spec itself in quite a while, and seeing those simple pentagonal diagrams brought back some memories. I created those with Visio a long time ago. (Nowadays my Visio skills have gone completely to pot, but for various recent slideware projects I’ve ended up getting a lot of facility with drawing in OpenOffice; I’m using V2 Beta and it uses the OpenDocument .od* format, which seems to fix some drawing bugs associated with the V1 .sx* format.)

I used to be dubious about XLink’s move to a purer arc-oriented architecture, partly because it seemed to be going a fair ways down the same path as RDF (although it did make harvesting RDF statements out of linkbases really easy) and partly because it seemed to optimize for model purity at the expense of hyperlink ease-of-use. Then again, simple links did include some syntactic sugar, and now they’ve got even more. It would be funny and fitting if simple links became popular and then started being harvested for their resource description properties.

(Post title offered in the spirit of Norm’s post here… Or should that be “draught”? Maybe when referring to a collection of DocBook specs!)

I was scheduled to give a talk last week at the XBRL (Extensible Business Reporting Language) conference in Boston, on the topic of using Liberty Identity Web Services (ID-WSF) and other modern web services security standards to secure and authenticate XBRL-based financial report data. Unfortunately, just a couple of weeks before showtime, I was “cordially required” by my management to attend a different event and had to bow out, but my colleague Farrukh Najmi kindly offered to cover the session for me. Thanks, Farrukh! He and I worked to together to develop the content, which was an absolute pleasure.

Farrukh’s main specialty these days is ebXML Registry, whose latest spec version has a nice connection to both SAML and XACML; it defines how to do web single sign-on to a registry through a fairly thin profile of SAML, and also defines a binding to XACML for managing registry access control. This is a great example of reusing existing standards in an elegant and appropriate way. (By the way, if you happen to be an OASIS member and your company rep hasn’t yet voted on V3.0 of ebXML Registry, make sure they do so before April 30. I hope you’ll support its bid for OASIS Standard status.)

In similar fashion, the XBRL folks have been working away on their highly specialized language for business reports, but have recognized that the infrastructure — for example, secure web services technology — that will support XBRL payloads is best outsourced as a design problem. In my research for the talk, I learned that these folks have some interesting goals for capturing security assurances on report data, as well as for representing them in a GUI. For example, one fellow described to me how a reader of a financial report should be able to visually peel back the layers of trust on a statement such as “I, the auditor, certify that this electronic report corresponds to the official printed one.” They also have some classic access control concerns in the early stages of report development, though once a report is filed, everything switches to a “business-to-anonymous” pattern — anyone must be allowed to read the thing. (The Gilbane Report blog has some comments here about XBRL and its applications.)

Technologies like XML Signature, XML Encryption, WS-Security, SAML, XACML, and Liberty ID-WSF could potentially all get into the act to make XBRL security nirvana happen, but there’s no one obvious way to use them out of the box to achieve the desired results, so the next step called for is a deeper exploration of use cases and, most likely, some profiling activity. Just as ebXML Registry did, XBRL might find that reusing these security standards can be a feature goldmine.

Along with spring bulbs (so prettily captured here) and new leaves, we have the call for participation for the North American XML conference series… The conference is November 14-18 in Atlanta, GA this year, so perhaps a few of those leaves down south will still be attached to their trees by showtime!

I’m no longer on the program committee, having done that for a few years running, but will serve as a paper reviewer this time around. I was glad to learn recently from conference chair Lauren that the planning work was going well. (I wonder if they’ll still let me run the artwork exhibit?)

Last night I caught the tail end of a new snarky TV show that seems to portend the end of civilized society: Craft Corner Deathmatch. They are definitely channeling The Running Man here. I do like the moment in the show where they tell each contestant to “Defend Your Crap!” A good discipline for us all…

There was a short-lived tireblogging trend a few months ago, of which this was an example. It’s an account of flat-tire fixing in Nigeria; tube tires are commonly used, which is an annoyance because of the “pointy paraphernalia” often found on West African roads. A cottage industry of “Vulcanizers” (tire patching businesses) has grown up to make the frequent fixes needed. The tubeless alternative generally requires a fancy and expensive air pressurizer to work with, so it’s not as widely used.

I was reminded of this tale while reading the latest instance of the SOAP vs. REST permathread on the xml-dev list. Dare Obasanjo characterizes the difference as rich vs. reach, which a lot of people picked up on as a useful distinction. But while Dare means “rich” in the sense of “richer, more fully featured”, some others in the thread provide evidence that you have to be richer to afford SOAP! Leigh Dodds notes:

There was a lot more pain involved in implementing even simple SOAP services, and debugging them once they were up and running. We’re now using RESTful APIs and these have proved to be successful. They also feel easier to work with: I’ve been merrily applying XSLT to RESTful interfaces to generate HTML forms for applications, shell scripts using curl to implement management and testing tools. Feels a lot more agile. …

I’ve also noticed that our RESTful APIs promote a better understanding of our internal models: rather than a list of function calls, we’re sharing resource models. Not to be sniffed at for a small shop that needs to be able to move engineers between projects easily.

Elsewhere in this thread, Michael Champion provides specifics about the richness he think you give up with REST: “confidentiality, reliability, and protocol neutrality”. But I’m not sure I buy the idea that you miss out without SOAP.

First, confidentiality: As Elliotte Rusty Harold points out, it’s not like XML Encryption doesn’t work on arbitrary XML as well as SOAP messages — and of course the same goes for XML Signature. (WS-Security is a profile of these for web services that contains some good work, but it’s an extremely generative framework and must be further profiled to be used in a secure and interoperable way — one proposal suggested that it needs scores or hundreds of templates just to ensure security! Profiling XML Encryption and XML Signature directly for a generic XML-over-HTTP messaging system could easily be just as functional as WS-Security.)

Second, reliability: Although IBM’s proposal from a couple of years ago for reliability with HTTP, called HTTPR, hasn’t swept the distributed computing world, we now have the credible HTTPLR proposal from Bill de hÓra. Choices do exist here.

Finally, protocol neutrality: I’m confused as to why this is an inherent good. Even if you’re neutral wrt HTTP, don’t you have to be specific wrt SOAP? I understand that there’s the potential for benefit as you move up in abstraction, but there’s the potential for cost as well, since each new higher layer tends, for a significant length of time, to be less mature, less well standardized, less interoperable, etc. And of course, what might be called the “SOAP family of specifications” (a phrase that gives me pause, especially in light of Norm’s post on problems in the XML family of specifications) has given rise to opportunities for, um, let’s call it vendor job security that no longer exist at the widely deployed level below.

I’m not against luxury items — lovely sturdy Mercedes tubeless tires — for those who can afford them, but it seems that the technologies with “reach” have achieved a fair amount of richness using common items that can be found around the home, and deserve not to be dismissed as mere toys. Reach is powerful all by itself. Perhaps the critical tube-tires-and-Vulcanizers lesson is that simpler materials and technologies often have a better habitability quotient, something Leigh Dodds’ comment quoted above demonstrates. I don’t often see this factor taken into account explicitly, but it makes a critical difference at the economic margin — and keeping in mind that “reach” is another way of saying “wider adoption”, I’d venture to say that good habitability is a necessary condition for it.