From: Dan Brickley (Daniel.Brickley@bristol.ac.uk)
Date: Fri Aug 11 2000 - 09:31:27 PDT
Hi Dave,
On Fri, 11 Aug 2000, Dave Winer wrote:
> Dan thanks for the thoughtful response, but this is a slippery slope.
>
> I fear it's hopeless. XML, as promoted by the W3C, is not for people who
> love the Web. We continue to have this argument. It's a total waste of time.
OK, except that I do love the Web, and I quite like XML too, especially
namespaces (the most Webby bit of XML, from where I'm standing). So
somehow we're looking at the same technologies very differently. I think
it is worthwhile trying to pin down the root of this disagreement.
XML is SGML-lite for the Web. And we also still have HTML in our
toolkit, which I've also a soft spot for. The Web took off, as you point out,
because cool things were easy to do. And then it all got a bit hectic
for a while (browser wars etc) because the HTML spec became the focal
point of industry jostling, with everyone wanting their own tagsets to
become part of _the_ core Web data standard. A miserable
business; people with creative ideas, experimental extensions, neat
addons etc found themselves in a situation where they had to choose between
spending hours arguing their corner in commitees versus going it alone
with uncoordinated proprietary extensions. Neither being fun. XML
(particularly with namespace support) directly addresses this, by
allowing dencentralised, principled extensions. Without the need for
committee design. I can tell the <danbri:blink> tag from the
<dave:flash> tag because both are given Web names (URIs) and therefore
grounded in a single information space. While we can each submit our
<blink> and <flash> vocabularies to standards-oriented organisations
for blessing and approval (or not bother), XML allows us to get on with
the job of building tools and services without forcing us to do
centralised design by committee. This is good, it creates a marketplace
where different XML vocab can safely be mixed without having to
pre-coordinate DTDs for each and every possible combination of
independently developed XML vocabularies.
What's the alternative? Here's one. We stick with the old HTML model and
pour a whole bunch of interesting/useful constructs into one monolithic
toolkit for data interchange. I don't mean to be dismissive: most RSS
applications that I've seen to date could have been done using a subset
of HTML 4.0 functionality. XML, as you say, offers possibilities (and
potential complexity) beyond that familiar from traditional HTML/Perl
web hacking. RSS being an interesting example. As soon as we start to
go beyond using RSS as a slightly richer form of HTML bulletted lists,
we risk re-experiencing the HTML bottleneck situation. XML namespaces
is one strategy for avoiding this: we build some lightweight scaffolding
that all applications can understand, then allow that structure to be
augmented in a dozen different ways by independently managed, uniquely
named extensions. The useful ones will get used, the others shouldn't get in
the way. XML namespaces isn't the only way, of course. We could either
bite the bullet and invent a dozen committees for integrating
independent extensions into a common core markup language, or we could
(re)invent a modularisation strategy to avoid the HTML/bottleneck
problem. Either way, we find ourselves battling the very problems XML
and XML namespaces came along to help solve.
>
> Try a mental exercise. RDFize RSS. Add namespaces. Let the schema people
Funny you should mention that...
As it happens, I've been RDF-izing RSS in my implementations since the first RSS
specs. I could't think of a better way of aggregating RSS data with
sitemaps, typed links (HTML, XLink), embedded bibliographic metadata,
shared bookmarks etc. Suggestions welcomed! ('use RSS for all of the
above' not being a plausible alternative...)
> have their way. What once was something that any HTML coder and Perl
> scripter could understand becomes a bookshelf of arcane specs and minutiae.
Point taken; increased complexity comes with a pricetag and with
responsibilities on those advocating extra complexity. We need simple
interfaces for common XML/RDF tasks. Web application authors shouldn't
have to digest the XML InfoSet doc nor understand RDF's reification
machinery. There's a bunch of stuff people are using XML for that
plain ole HTML works just fine for. And there's plenty of evidence
(eg. see Ian Davis' recent RSS implementation survey,
http://www.egroups.com/message/syndication/330 ) that "any HTML coder
and Perl scripter" -- including me! -- is likely to goof even with a
relatively simple XML application like RSS:
RSS 0.90 unparsable: 22 (11%, was 6%)
RSS 0.91 unparsable: 198 (14%, was 6%)
If this survey is accurate, the 'simplicity' argument against namespaces
needs to be reconsidered. Any XML-based application will be implemented
badly if the Perl-hackers concerned don't understand XML. And who
can blame them. It isn't clear to me that the addition of
namespace-based modularity will make the situation any worse. On the
contrary, the use of namespaces may allow at least some partial
understanding of buggy data, since the core guts of RSS needn't
change much when people invent ways of representing jobs, mp3s, image
metadata, etc etc within an RSS-based framework.
Following http://www.egroups.com/message/syndication/218?&start=189
it's put up or shut up time. I'll shut up on this for now and get back
to hacking...
> I thought FoRK was a good place to discuss this, Adam put me in the mood
> last night, blame him not me ;->. Frustrated that we can't have one little
> part of the Web that doesn't get The Treatment.
FoRK's a *great* place to discuss this. Wasn't called FoRK for nothing ;-)
If by 'get the treatment' you mean 'adopt an architecture that allows
decentralised extension' I'm inclined to disagree. While HTML was the
one true data format, a monolithic data format just about made
sense. In XML-land, we have to expect our data structures to be
aggregated with those defined elsewhere. Especially when our target application is
Web-based data aggregation. This means figuring out our own way of doing
decentralised modularisation or else buying into namespace/URIs etc (an
easier option IMHO) then getting back to the fun stuff, ie. building
Web-data aggregators from Perl, SQL and sticky tape...
IMHO etc.,
--danbri
This archive was generated by hypermail 2b29 : Fri Aug 11 2000 - 09:35:31 PDT