XML and XSLT a Remedy for Vendor-Specific APIs?
The Web Directions panel discussion came around to the topic of APIs and the problem of learning a new one for every web service or having to deal with the problems of integrating those APIs into the particular systems that need to support them. To me this raised the question of why we are using APIs rather than a standard way of sharing data. It seems that XML, XHTML and XSLT would be all that we would need if,
- The browsers supported the W3C recommendations for the language of the web
- Developers were using the specs correctly
- Designers understood the importance of the semantic web and treated content as an opportunity to serve content in fluid and dynamic forms rather than as pixel perfect design templates
If XML is the language of the web, why do we, both designers and developers, keep screwing it up? From what I’ve heard over the course of the weekend, it appears that the stalemate over who would drive the future of the HTML specification, whether the W3C or the WHATWG, was over a question of theoretical purity on one side and practical considerations regarding the way the majority of the web development community was using HTML on the other.
Order Out of Chaos
I’m an ideological purist, I suppose. But I see the concessions as just that: conceding to defeat over the standards that the web standards community have been advocating for. Having discovered XSLT, I have a hard time understanding why the language is not being used, supported, and further developed. It is incredibly powerful and flexible, and for a HTML/CSS designer like myself, it made a lot more sense to take a month to learn XSLT over a year to figure out a scripting language such as Perl, PHP, Ruby, Python, or JavaScript. Not that I don’t have an interest in learning any of these languages, but in the interests of not repeating myself, I would much rather learn something that extends what I already know, which is XML, HTML and CSS.
I recall discovering a reference to XSLT in a discussion by the developers of Drupal about what templating language to support. The decision to go with a proprietary templating system over XSLT was as a result of a desire to attract as many PHP programmers to the project as possible, and the problem with XSLT was that it demands a different approach to programming that would have been unfamiliar to the typical PHP programmer. I’m sure many of us may have been saying the same thing about CSS a decade ago.
Now if the same argument is being made about the direction of the HTML specification, to introduce new elements that emulate many of the classes and IDs that developers are currently using to build sites, that’s all well and good. On the other hand, is it trying to force legacy structures with parallels in a static print design world into the web, where, in semantic hierarchies, the definitions are actually too vague to have any real meaning.
If, as Mark Boulton put it, we are trying to create order where there is chaos, we really must concede that what we do in fact have is chaos. We have several different scripting languages, almost flavours of the day, that we as designers and developers must try to contend with on a daily basis.
The plethora of devices and user agents that are being used to serve all this content, each using their own proprietary methods and interfaces to serve their own needs, often over the needs of the user, further confuse and complicate the problems that we deal with. Do we expect things to be easy? No. Just easier.
What is a Designer?
During the panel discussion about just what does it mean to be a (small “d”) designer or a (big “D”) Designer, I was reminded of something that Dr Tony Golsby-Smith remarked in his talk on the theme of Design Currency, Defining the Value of Design at the Icograda Design Week conference that took place recently in Vancouver, Canada. “Design,” he said, “is a system where humans create what can be other.” In other words, designers are agents of change. We see that something is one thing, but we envision how it could be something else, something better. And then we do something about it. He reiterated, “Our job is transforming: things can be other than they are.”
The way that Tony expounded his point was to start with the art of thinking, pointing to the Greeks and the birth of Democracy as the turning point at which we realized that people’s lives hung in the balance when people were given the power to decide who should rule them and how to decide whether someone should live or die based on the laws of the people. “How do we make decisions, if the people are deciding the fate of people?”
The promise of the information revolution was that we would have more information, more data, on which to base our decisions, thus our decision making would be far more effective. I believe we can safely say that this is not the case. The recent economic downturn may be a case in point.
A Crisis of Control
So, what we have in our modern times is a crisis of control. We want control in the face of chaos, but we don’t have any. Thus we have something called postmodernism. Which is really just a reference to the reaction of modern day managers to modern management theory, in the words of Dr Tony Golsby-Smith, “Oh shit! It’s not working.”
It seems that what we have in development circles is a confusion of languages, a Tower of Babel, where each development culture is approaching very similar problems from a specific linguistic bias. We have become impatient with the self appointed standards body, the one who claims an ojective truth and a set of laws that we should all conform to. So the people would rather go their own individual ways.
If we are all both designers and developers, agents of change, how do we envision a better future? As a front-end designer with a little development knowledge, I would much rather we follow the rules and recommendations that we already have. We’ve learned from experience that when people stray from that we may end up saying, “The internet is dead, and I killed it.” Perhaps XML is too verbose. Perhaps it is not always the best format to work with. But HTML has served us quite well so far. To store information in other ways almost seems redundant.
Maybe the argument is more a practical decision, rather than a purely theoretical concern to ignore XSLT. As with SVG, where lack of browser support has largely rendered it a dead language, perhaps the same is true with XSLT.
While Jeremy Keith may say, “Be careful what you wish for,” I do wish for the ability to have more control over the data as a designer. Design is as much about the structures of the data as it is the presentation. As the power of scripting languages and databases has usurped the static HTML document, the control over data structures become more distant from the designer. My contention is that XSLT is comprehensible by a designer who knows how to select nodes in an HTML document structure, even if the programmers find XSLT obtuse. By using XSLT as a common templating language, more power can be placed into the hands of designers to affect change, while at the same time simplifying the role of the programmer to be able to efficiently model and serve data. Designers can then concern themselves with both the semantic structure and visual presentation of the content without worrying about the limitations of any scripting language, framework or CMS.
Personally, I would much rather the bedrock of XSLT, a W3C standard, than the shifting sand of the plethora of proprietary templating languages.
