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 07:24:11 UTC