Never-converge-itis (was Re: XML matters for the Web - and the browser)

[Dave Winer <dave@userland.com>]

Simon this is a wonderful example of "I'm only looking for bad news."

Instead of telling them about our failures, why not tell them about how XML
can help build flow for their sites and make them more efficient as web
developers.

This list and the community it defines suffers from the same problem,
never-converge-itis.

Edd did the same thing last month with XML-based protocols, declaring the
industry moribund because he only goes to conferences and doesn't pay any
attention to the accomplishments of independent developers working over the
Internet itself.

You missed RSS, it's a great flow-builder, and defines whole communities.

For some reason the failures are more interesting to you guys.

I'll never figure this out, maybe you can help illuminate.

Dave

PS: For people who are waiting for content-separated-from-form at the
browser level, you might try doing it in a CMS and depend on the browser
only for the most rudimentary formatting. It works. You'll wait forever for
the browser guys to do it in a reasonable way. This was just as true in 1996
as it is today. Time's a wastin!!


----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: <xml-dev@lists.xml.org>
Sent: Saturday, September 08, 2001 11:04 AM
Subject: XML matters for the Web - and the browser


> 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.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>