Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] best practice for providing newsfeeds ?

From: "Joshua Allen" <joshuaa@---------.--->
To: "Michael Champion" <mc@-------.--->,"XML DEV" <xml-dev@-----.---.--->
Date: 2/2/2004 8:35:00 PM
> liberal.  The question is whether this success will continue once
> serious businesspeople get into the act, when real money is at stake,
> when lots of people start syndicating information that is mostly
> processed by machines (calendars and schedules data that would be

OK, is it fair to paraphrase this argument as "RSS works fine today, but
Atom will enable you to be more flexible in seizing new opportunities
tomorrow?"  This is certainly the sort of argument that is directed at
businesspeople instead of techies, but it still comes across as FUD.  I
say FUD because the argument so far is unsubstantiated by any real-world
examples that would make someone at NYT pay attention.  And the converse
could easily prove true.

You also raise the point of "steeped in XML best practices", which is
probably fair to classify as a philosophical argument.  If we are
concerned about architectural purism, and want a way to exchange
calendar information (and it's not clear that there is customer demand
for RSS to do this anyway), I would argue that RDF iCal is the best
practice.  In fact, based on that I always thought that R(DF)SS 1.0 had
the unassailable high ground with respect to purity of practice (as
opposed to RSS's "loose consensus and running code").  For people
concerned about best practices, why would anyone abandon RSS 1.0 and
jump to Atom, especially when RDF parsers are *finally* becoming
widespread?  I hear Danny's unbridled optimism that "one day RDF will
work well with Atom", but we have heard that song and dance before.  Why
anyone who cared about RDF would abandon a perfectly good RDF-based
format in favor of a format that "might one day work great with RDF" is
beyond me.


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent