XSLT was James Clarke’s Joke ?

Came across this interesting exchange in xml-dev mailing list.

Norman Gray says:

“I still very strongly suspect that XSLT was a James Clark joke.  After being told that DSSSL would never take off because it had the wrong shape of brackets, is it not the case that he came back with a spoof mini-subset of it which had the right brackets, but which was received with such rapturous acclaim that he never had the heart to confess it was intended as a gag.  No?”

Having spent good bit of time myself on using XSLT, I couldn’t believe that XSLT was a joke. Anyway,  Henry  S Thompson was quick to assert that it was not a joke 🙂

“No. I was there. The decisive breakthrough in the DSSSL->XSLT move
was the realisation that by writing XSLT _in_ XML we could make the
‘output’ side of templates iconic — that is, instead of _describing_
the desired result tree fragment, as DSSSL has to do, we could
_manifest_ it.”

And Michael Kay (love his XSLT book) responding:

“No, the use of angle bracket syntax was to filter out undesirable users
whose minds had been corrupted by use of curly braces. This had the entirely
intentional consequence that the language is happily used (a) by people who
would otherwise be writing HTML and can see that XSLT is similar but does a
lot of the work for you, and (b) by programmers who are sufficiently
open-minded to see the deep beauty of the language through its superficial
ugliness, while scaring off the Javascript kiddies who don’t deserve such
good tools.

In fact, using XML as the syntactic basis has many benefits. The most
notable one for me is that it is very easy to extend the language: whereas
XQuery goes through anguish every time a new construct is added, because of
the ambiguities and inconsistencies introduced by new grammar, XSLT is
infinitely extensible through new elements and attributes with no problems
at all.”

Unified Models for the Cloud

Today, I came across several posts, starting with Lori MacVittie‘s post on “A Unified Model” where she talks about her dream to come up with a unified model across the layers of the cloud:

“If we could agree on a unified model to codify the meta-data necessary across the entire spectrum of application and network infrastructure services and then further agreed to standardize on a REST-based API we could, in fact, arrive at a point where the issue of cloud interoperability is resolved with little more than a URL rewrite.”

“If the model is consistent across cloud computing environments – public, private, hybrid, local, external, internal – much in the same way HTML is consistent across web applications, then the differentiation across providers becomes the services and processes that orchestrate those services into an efficient, fast, secure application delivery system. If the model is consistent then an application can be described in a consistent, unified way and the implementation of the policies required to support the application and its infrastructure needs (security, acceleration, QoS, optimization, data integration, backup, storage) remains the demesne of the cloud computing provider.”

In this context, it is also interesting to read her older post “Cloud, Standard, and Pants” with an analogy to the problems women face in correlating the sizes across brands.

In the end she summarizes:

“We need to focus on the models, not the APIs, because it is the models that will provide the interoperability and portability desired both across and within cloud computing environments.”

Great post. Echoing similar thoughts on the Cloud API standards, back in Septembr’09, in my post on “Do we need Cloud API Standards”, I argued that we need to have underlying models compatible before coming up with a standard (Unified API for example). As it stands, the models vary quite a bit and unless these are addressed, interoperability will not succeed.