OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Bits vs APIS - was Excellent Insight on Standards Developm

[ Lists Home | Date Index | Thread Index ]
  • To: "Michael Champion" <michaelc.champion@gmail.com>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Bits vs APIS - was Excellent Insight on Standards Development vs Invention
  • From: "Dare Obasanjo" <dareo@microsoft.com>
  • Date: Sat, 13 Nov 2004 13:46:58 -0800
  • Thread-index: AcTJiep0aC83cvqRRVq6DTAOeyEKcwAPzirm
  • Thread-topic: [xml-dev] Bits vs APIS - was Excellent Insight on Standards Development vs Invention

I'm not sure where Sean is coming from. From a purely syndication perspective, the existence of Atom makes it even more likely that application developers would hide behind APIs instead of working with bits on the wire. With RSS 0.91/2.0 & RSS 1.0, a feed consumer could write fairly straightforward code to parse either format with just a few if...else blocks to deal with the minor differences (e.g. in RSS 1.0 the <item> elements are not a child of <channel>). Now with adding Atom 0.3 and then Atom 1.0 to the mix, it is more likely that a syndication consumer would just want some API that hides the syntactical variaations of all the various XML syndication formats instead of dealing with each one individually using an XML API. 
 
As for Mark Pilgrim's article, it's always good to seperate fact from opinion. The fact is all the major weblog APIs are XML-RPC based today. The folks involved in the Atom API discussions have built a RESTful API but there is a vocal contingent [including Google, the biggest vendor proponent of Atom] who claim that it is a non-starter with a SOAP API story which to me isn't much different from being XML-RPC based. 
 
-- 
PITHY WORDS OF WISDOM
There is nothing more satisfying that having someone take a shot at you, and miss. 

________________________________

From: Michael Champion [mailto:michaelc.champion@gmail.com]
Sent: Sat 11/13/2004 6:05 AM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Bits vs APIS - was Excellent Insight on Standards Development vs Invention



On Sat, 13 Nov 2004 12:30:20 +0000, Sean McGrath
<sean.mcgrath@propylon.com> wrote:

>
> My take is that Atom is about sorting out the "bits on the wire". Sorting out the "bits on the wire" is, to my mind, infinitely better than hiding everything under an API.

I don't know much about the RSS/Atom controversies, and regret it
every time I get involved, but what Mark Pilgrim says in
http://www.xml.com/pub/a/2003/10/15/dive.html about the weblog APIs
makes sense to me.  The conclusion that they have moved from an
XML-RPC orientation  "back to a document-centric, REST-inspired
service again"  would resonate with RESTifarian docheads, I would
think :-)

>
> A lot depends on ones attitude to APIs.

Yes.   I think the bits on the wire vs APIs permathread has a similar
theme to the XSLT vs SQL/XML or XQuery thread a few days ago.  Again
it's clear that there is a certain group of people, generally
docheads, often those who have lived with SGML and friends for at
least a decade now, who are very comfortable with thinking of XML as
bits on the wire:  They have a mindset and elegant set of tools that
lets them do what they do quite efficiently and effectively.  For
better or worse, however, they are out of the mainstream of the
current IT industry, where people are *generally* (again, I think by a
10:1 or so margin) more comfortable thinking in terms of abstract data
structures, algorithms that operate on them, and APIs that encapsulate
this and hide the raw data.

For example a quote from Pilgrim's article: "There are XML-RPC
libraries for very many programming languages, so you'll never have to
see or think about the raw wire format. Until you need to debug it, of
course."  The downside of encapsulation is definitely that you can't
get in and fix it if it goes wrong (sortof like modern automobiles
that virtually no 'shade tree mechanic' can fix).  The upside is that
this creates higher expectations:  the big company that wrote the
library, or the army of geeks who wrote the open source tool are the
ones expected to get it right the first time.

There really is room for all in our little ecosystem:  Architecture
Astronauts who think great thoughts, design high-level interfaces,and
write whitepapers are useful to have around to talk to the Gartner
Group ... Hard-Rock Bit Miners are useful to have around when things
go wrong in the cellars of the ivory tower, but there is a great bulk
of people in the middle who just want to get their job done and go
home.  I'm sure that this list has a disproportionate percentage of
people at both ends of the distribution, but at the end of the day its
the folks in the middle who pay us.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>







 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS