XML matters for the Web - and the browser

["Simon St.Laurent" <simonstl@simonstl.com>]

I spent the last part of this week at the WEB2001 conference in San 
Francisco, finally returning to the Web development world from which I came 
to XML.  My presentation - "XML's Impact on Web Development" - started off 
with pretty much an apology.  While XML was originally designed as "SGML 
for the Web", it seemed to have landed pretty much everywhere in computing 
except the Web.

The XML community has not spent much time reaching out to Web developers, 
and some members (including vendors) in the XML community seem intent on 
rebuilding the Web in a far more complicated style.  The tools used for 
HTML Web development, many of which are easily applied to XML, are widely 
disparaged rather than encouraged as gateways to new possibilities.

CGI/ASP/JSP/ColdFusion/PHP/etc. can be used to generate XML documents, and 
Web developers familiar with such tools can shift their skills to the 
lately more lucrative universe of XML communications.  Parsing XML isn't 
rocket science, and can be done in those contexts with little more 
difficulty than connecting to a relational database, something that happens 
every day.

Instead of reusing these tools and skills, however, buzzword-compliant 
vendors seem intent on creating systems which sell at far higher prices and 
rarely provide that substantial an abstraction.  Maybe programmers shun the 
notion of hiring Web developers to perform this kind of work for cultural 
reasons, but the people with the skills are out there.

On the client side, it's not very difficult to present XML documents in a 
Web browser.  Really!  Cascading Style Sheets, an existing technology 
well-known by a substantial number of professional Web developers (and 
substantial numbers of amateurs), is perfectly capable of describing 
complex browser-based presentation of XML documents.  There are some gaps - 
CSS doesn't yet allow developers to specify 'element X is an image', 
linking is in its infancy, and forms remain a problem - but there are 
workarounds for all of these.

Instead of reusing CSS and enhancing it to support the few remaining gaps, 
however, a lot of people insist that HTML is the one true way, the lingua 
franca.  Some argue that developing Web pages in XML is a waste of time, 
others argue that creating content in XML is great but that XSLT 
transformation are a required bridge in the publication process, somehow 
fundamental to the workflow.  Some browser vendors - notably Mozilla and 
Netscape - have realized that XML+CSS is powerful stuff.  Other browser 
vendors seem content to perform strange internal transformations between 
the XML+CSS and the HTML they've known so well for a long while, leaving 
XML developers faced with either a severely diminished presentation palette 
or the learning curve of XSLT.

What are we losing here?

Those who push HTML for presentation and XML for data storage give the rest 
of us much less flexibility in our own development processes.  Steeper 
learning curves are one cost, but the continued push to send HTML, even 
slightly cleaned-up XHTML, to the client leaves us in a straitjacket.  HTML 
does a barely adequate job of representing information.  There are plenty 
of kludges, workarounds, and wild solutions built on top of HTML, since 
it's "what we've got", but HTML seems quainter and quainter as time 
passes.  ("Barely adequate" was a compliment when HTML first appeared, but 
don't mean it that way today.)

Working with HTML means abandoning the notion of sending rich content to 
clients who can process it independently of the server-side processing that 
dominates most Web applications.  There are those who don't care to send 
rich information, but there are also those who are tired of spending huge 
sums on servers while browser clients spend their time idle.  XHTML offers 
some prospect of improvement, but the specifications seem so obsessed with 
validation that the work/benefit ratio of rich XHTML documents is tilted 
heavily toward the work.

Working with HTML also limits communication within organizations.  A lot of 
sites have found that WYSIWYG tools simply can't meet their needs.  As a 
result, there are a lot of HTML templates out there which contain comments 
like "news story goes here" or "enter date here".  If editors could work in 
XML, the labels might make sense, and the presentation dross (from a 
writer's perspective) could be separated out into CSS.  I have a very 
difficult time believing that people want to edit documents in an editor 
which shows XML in one window and an XSLT transformation in another 
window.  CSS offers much less overhead for such tasks.

Content management systems have their place, but I'd like to think both 
that they aren't necessary for the relatively simple scenarios I presented 
above, and that CMS can be enriched and simplified substantially by taking 
advantage of tools we already understand.

I have a hard time believing that "SGML for the Web" is fit only for 
servers, or that the "Web" in question is really the business-to-business 
communications of "Web services".  At WEB2001, it seemed like a lot of Web 
developers were taking notice of the options XML had to offer them, while 
still bewailing the notion that it takes a 1200-page book and a notion of 
transformative style sheets to make use of it.

Perhaps this would change if the Microsoft Office folks would notice that 
XML+CSS is probably a much easier way to integrate their information with a 
Web browser than is transformation to HTML.  Perhaps a shift in 
perspective, revaluing many of the reasons cited for doing XML in the first 
place, might lead us to ask how best to make use of the tools and 
experience we currently have available.

I've been in this wilderness for four years now, and I'm finally hearing 
(loudly, at that!) from Web developers that they're interested in using the 
tools we've worked so hard to develop. I'd like to make sure that we make 
it easier for people with years of experience on the Web to apply 
XML.  Sadly, much of the XML community and some of the HTML community 
insists that XML is some special discipline that requires technologies 
having little to do with the process of making rich information available 
on the Web to both humans and computers.
Simon St.Laurent
Associate Editor
O'Reilly & Associates, Inc.