Re: XML protocol comparison

On Sat, 20 May 2000, Dave Winer wrote:

> Hmmm interesting.
> 
> It totally makes sense that ICE would be used to distribute stories for
> media other than the web, but I'm not interested in any media other than the
> web. Any complexity that's added for the sake of other media that limits
> accessibility to small non-corporate publishers is going to beget a simpler
> protocol, which of course already exists, it's called RSS.

Supporting offline use of content doesn't add protocol complexity; it's
actually somewhat easier to implement in-line content encoding than
referential, since it eliminates a whole set of transport issues.

> Further, authors who don't have their own websites need not be left out! The
> barriers to having an individual website are coming way down. The tools are
> better applied to making that easy, imho, to decentralizing the web, which
> of course started out as a very decentralized medium.

I am all for lots of web sites. However, there are many scenarios, such as
a writer submitting stories to a publisher, where requiring the writer to
have a permanent web site on which they post their stories seems
inappropriate. We anticipate people being able to "Save as ICE" from their
word processor, for example. RSS seems more appropriate for web sites that
want to distribute headlines that link back to an ad-funded web site, or
publish "push" channels, neither of which sounds like the sort of thing
most individual writers are interested in. Perfect for Netscape Netcenter,
CNET, Yahoo, and so on, of course. Offline/batch operation requires more
protocol complexity, the same way that POP and NNTP are more complex than
SMTP, but once there are available implementations (and there are) the
protocol complexity allows for more satisfying user interaction.
 
> Another question -- are there any inexpensive or free ICE server
> implementations? Is there a weblog covering news of ICE deployment? How can
> I dip my toe into ICE without making a substantial investment in time or
> hooking up with someone like iSyndicate, or getting a personal tutorial? I
> tried to understand the ICE spec when it came out, and even considered doing
> a server in Frontier to undercut Vignette's price, but it was dauntingly
> complex, so we didn't pursue it. But two years have passed now, perhaps the
> situation has changed.

There's an open source ICE implementation underway, lead by Bruce Hunt at
Adobe. It should be up on SourceForge shortly. Personally, I think that
the availability of a GPL's ICE implementation (written in Java, btw) will
really expand the number of ICE networks.

Aside from that, ICE implementations for evaluation purposes are available
from ArcadiaOne and Xenosys, at no cost. Of course, in production they'll
want to get paid for their software.

In terms of learning about ICE, there are presentations on ICE at all of
the XML-related conferences. There's a book on ICE coming out in a few
months, co-authored by the AG members. And, of course, you can go to the
web site (http://www.icestandard.org) and read the spec -- we get a lot of
positive feedback on the thoroughness and specificity, so it's not a light
read, but everything's spelled out as explicitly as we can make it, with
lots of examples. One "trick" to reading the spec is to keep in mind that
all of the more complex aspects (e.g. negotiation, scheduling) are
"quality of implementation issues" that are, in effect, optional.

For example, ICE has complex scheduling mechanisms, but if you just want
to do what RSS does, you could implement a single ICE message
(ice-package) with full update, no confirmation of delivery, and including
items only by reference. This aspect of scalable complexity in the
protocol was a central design goal, but is something that we didn't
explain well in 1.0. 1.0.1 was primarily an "editorial" update that
clarified these sorts of issues; we made no DTD changes but clarified a
number of items based on feedback from implementors. 1.1, on the other
hand, reworked the scheduling and negotiation aspects to be more clear,
and added extensibility to the protocol. Between the two revisions since
you've read the ICE spec, I think it's worth another look.

If I get time over the weekend, I'll try taking an RSS "feed"
and recoding it in ICE to see how similar the protocols are. I'll post a
summary to the list.

I'd love to see an ICE implementation in Frontier, BTW. The value of
syndication increases exponentially as the number of participants
increases. And if there's a way to unify the two syndication standards (as
I mentioned in my previous email) I'd love to discuss it.
 
> BTW, I'm not assuming that all implementations are hugely expensive, these
> are real questions. A sample implementation in a popular scripting
> environment, that was free or inexpensive would do a lot to further an
> understanding of ICE and what its capabilities are, and help it achieve
> independence of Vignette, who is not known as a friend of the individual
> publisher.

That's entirely reasonable. There are a number of competing
implementations currently, each with rather different business models,
ranging from a per-syndication fee to an unlimited use per-CPU model.

The reference implementation is fairly sophisticated, in order to serve as
the basis for a validation suite. I would love to see a simple Perl module
to speak ICE, for example, in order to allow ICE to be more broadly
distributed.

> The sports scores application sounds quite compelling.

Glad to hear it. It was fun to build (www.majorleaguebaseball.com). In
fact, the difficulty of dealing with those ANPA-formatted wire feeds was
direct inspiration for my participation in the ICE standard effort.

> Dave
> ----- Original Message -----
> From: "Laird A Popkin" <laird@io.com>
> To: "Dave Winer" <dave@userland.com>
> Cc: <xml-dist-app@w3.org>; <eric@w3.org>; <bernhard.dorninger@scch.at>;
> <ice-ag@egroups.com>
> Sent: Saturday, May 20, 2000 4:24 AM
> Subject: Re: XML protocol comparison
> 
> 
> > It depends on your goals.
> >
> > Passing around pointers works if all syndicators operate large web sites
> > that they want to drive traffic towards. One of ICE's goals is to allow
> > small content creators without an online presence (and all of the
> > infrastructure that implies) to package their content for syndication by
> > service providers, aggregators, etc. Thus, ICE can be used by writers to
> > send stories to their publishers (for example) simply by dialing their ISP
> > and triggering an ICE "push".
> >
> > Shipping content rather than pointers also allows receivers to repurpose
> > the content, integrating it into their site directly from a structured
> > feed, rather than by retrieving web pages and attempting to reverse
> > engineer structure.
> >
> > Simple pointers, such as you propose, also have some synchronization
> > problems. That is, they work fine for content that changes relatively
> > infrequently. The delay between pushing out pointers and the retrieval of
> > the content should not be an issue for book reviews or headline news, but
> > doesn't work so well for small pieces of rapidly changing information such
> > as sports scores or stock tickers; for such applications, in-line content
> > transmission is more efficient and eliminates the synchronization issues.
> >
> > Additionally, retrieving content from pointers somewhat assumes that the
> > use of the content is on the web, and while ICE uses the internet as its
> > transport, there's no restriction on the manner of the use of the content.
> > ICE over the internet is being used as an alternative to proprietary
> > networks, for example, in applications that have nothing to do with web
> > sites.
> >
> > All that being said, there's value in both models (content transmitted
> > in-line or by reference), and both communication models are supported by
> > ICE. Thus, the content provider can determine which communication model is
> > appropriate for the specific application.
> >
> > For examples of ICE being used for content both in-line and reference, ICE
> > is being used both to syndicate the full text of stories (e.g. Reiters)
> > and to syndicate headlines that draw traffic to a web site (e.g. CNET).
> > And, at the protocol level, ICE packages support encoding content both
> > in-line and by reference. The intent is that for small pieces of textual
> > data, in-line encoding is more efficient, while for transmission of large,
> > binary objects, transmission by reference is preferable.
> >
> > On Sat, 20 May 2000, Dave Winer wrote:
> >
> > > Here's an example of why ICE doesn't work as a syndication standard
> (with
> > > apologies to Microsoft for using this particular story as an example).
> > > Scroll to the bottom of the article:
> > >
> > >
> http://dailynews.yahoo.com/h/zd/20000518/tc/standards_bearers_no_need_to_cry
> > > _wolf_1.html
> > >
> > > The writer says: "What's your take? Is Microsoft muddying the standards
> > > waters, or acting within its rights? Talk back below and let me know
> what
> > > you think."
> > >
> > > Look around and there's no place to comment. That's because the story
> was
> > > written for ZDNet, where presumably the readers have the opportunity to
> > > comment. On Yahoo, there's no place to comment, and even if there were,
> the
> > > comments would be disjoint from the comments on ZDNet, and perhaps a
> dozen
> > > other places this story appeared.
> > >
> > > A different model would for ZDNet to pay Yahoo for delivering a reader
> to
> > > the one and only place the story appears. That way if there were some
> > > excellent comments everyone could see them, and further, if there were
> more
> > > details to be added to the story, the author could add them.
> > >
> > > To me, this is a perfect illustration of the web being turned into
> email,
> > > and failing. The web is the web, pass around pointers, not stories.
> >
> > Keep in mind that ICE supports both "pointer" and in-line content. You
> > haven't "proven" anything about ICE. You have "proven" that you shouldn't
> > distribute data that is dependent on site-specific functionality. Instead,
> > if the data is by definition site-specific, you should syndicate "teasers"
> > that drive traffic to the source site. Or course, ICE supports this case.
> >
> > Shipping around "teasers" rather than content is great for web sites
> > exchanging editorial content (HTML) used in simple ways. And this is a
> > case that ICE supports, and which the ICE AG suspects will be a popular
> > early case of syndication; while it's of limited utility it is sufficient
> > for some applications, and fairly trivial to implement.
> >
> > Content syndication is not limited to web sites, or HTML. Indeed, many of
> > the more interesting applications involve business-to-business data
> > exchange, such as National Semiconductor's use of ICE to exchange parts
> > data with its business partners.
> >
> > And, of course, editorial content can be used in more sophisticated ways:
> > aggregators typically merge many different feeds into their site, where
> > the content is merged into a content management system for a wide range of
> > uses. For example, some content may flow directly to a web site, other
> > content may be indexed into a resource database for reference use, other
> > content may be "sliced and diced" into component elements for use across a
> > web site. A typical example would be sports scores, which are transmitted
> > in messages that contain a variety of scores for games being played. That
> > single incoming message must be parsed into its component scores, which
> > are stored in a database that is used by a web site that generates pages
> > for current games, team records, and so on, meaning that one incoming
> > message may cause dozens of web pages to be updated in relatively complex
> > ways.
> >
> > ICE supports the trivial case that you prefer (push files by reference,
> > whenever the sender wishes). It also supports in-line content encoding,
> > pull, confirmation of delivery, negotiation of delivery means and
> > schedule, state management, auditing, meta-data regarding intellectual
> > property, atomic use, copyright, etc., all of which are important in the
> > business of content syndication. Just to make it clear, ICE was designed
> > by a collection of companies with decades of experience in content
> > syndication across a wide range of media and industries. To be a valuable
> > protocol for allowing that business to efficiently and reliably operate
> > over the internet using a standard protocol, ICE needs to do more than
> > simple "ship around pointers."
> >
> > That being said, I would be interested in spending time with you to walk
> > through the "minimal set" of ICE functionality. Our goal was to allow
> > implementors who chose to support only the simplest case to implement a
> > very small number of messages.
> >
> > I suspect that if you look closely, ICE can be used to implement the case
> > you prefer quite easily; it's just not restricted to that case.
> >
> > > Dave
> >
> >
>

Received on Saturday, 20 May 2000 09:41:24 UTC