xml-dev - Re: blocks

["Dave Winer" <dave@userland.com>]

It sounds like the overlords of IETF got over their issues with XML
scalability.

Just in time for NIH. ;->

Anyway, it's predictable, there will be many payload formats, because as
revolutionary as XML can be, it can't overcome human nature. "I invented it
first," is the same argument we've been having ever since computers crawled
onto land and said "hello world."

Dave


----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: "XML-Dev Mailing list" <xml-dev@xml.org>
Sent: Thursday, July 06, 2000 6:00 AM
Subject: blocks


> Are folks here watching the development of the Blocks Extensible Exchange
> Protocol?  I've seen BXXP described as 'HTTP on steroids', but it looks
> like it may well be something else entirely, and perhaps more appropriate
> to XML exchanges on various scales.
>
> I wrote a blip on xmlhack.com about it yesterday, when the IETF chartered
a
> working group:
> http://xmlhack.com/read.php?item=637
>
> This morning I woke up to find three new Internet-Drafts:
>
> On the Design of Application Protocols
> http://www.ietf.org/internet-drafts/draft-mrose-bxxp-design-00.txt
>
> The Blocks eXtensible eXchange Protocol Framework
> http://www.ietf.org/internet-drafts/draft-mrose-bxxp-framework-00.txt
>
> Mapping the BXXP Framework onto TCP
> http://www.ietf.org/internet-drafts/draft-mrose-bxxp-tcpmapping-00.txt
>
> Here's a blip from 'On the Design of Application Protocols' regarding XML:
>
> >We chose XML as the default because it provides a simple mechanism
> >for nested, textual representations. (Alas, the 822-style encoding
> >doesn't easily support nesting.) By design, XML's nature isn't
> >optimized for compact representations. That's okay because we're
> >focusing on loosely-coupled systems and besides there are efficient
> >XML parsers available. Further, there's a fair amount of anecdotal
> >experience -- and we'll stress the word "anecdotal" -- that if you
> >have any kind of compression (either at the link-layer or during
> >encryption), then XML encodings squeeze down nicely.
> >
> >Even so, use of XML is probably the most controversial part of BXXP.
> >After all, there are more efficient representations around. We
> >agree, but the real issue isn't efficiency, it's ease of use: there
> >are a lot of people who grok the XML thing and there are a lot of
> >XML tools out there. The pain of recreating this social
> >infrastructure far outweighs any benefits of devising a new
> >representation. So, if the "make" option is too expensive, is there
> >something else we can "buy" besides XML? Well, there's ASN.1/BER
> >(just kidding).
>
> This is very intriguing work!
>
> Simon St.Laurent
> XML Elements of Style / XML: A Primer, 2nd Ed.
> http://www.simonstl.com - XML essays and books
>
>
***************************************************************************
> This is xml-dev, the mailing list for XML developers.
> To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
> List archives are available at http://xml.org/archives/xml-dev/
>
***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************