Re: WhatIsAtomFor

[James Aylett <james@xxxxxxxxxxxx>]

On Sun, Oct 26, 2003 at 10:28:49PM -0500, Seairth Jacobs wrote:

> http://www.intertwingly.net/wiki/pie/WhatIsAtomFor
>     
> I do not understand why this issue is being quietly closed.  Does everyone
> really agree on what Atom is for?

My feeling is that:

 * the majority of people have a clear idea of what they think Atom is
 * they assume everyone agrees with them
 * so they aren't getting invovlved in what would be a pointless
   exercise if the above two points were true

Also:

 * there isn't concensus except in small subsets of the Wiki community
 * there may be concensus, or at least majority agreement, on this
   list

IMHO this issue should be fairly quick to close, but that's because I
have a clear idea of what Atom should be, and am convinced I'm right
:-)

A quick (ish) thought, feel free to disagree with me completely:

  One of the strengths of having a single format for feeds (say) is to
  lower the bar for producers. Having it well-specified also lowers
  the bar for consumers. Having it extensible in a clear fashion
  lowers the bar for innovators (not even bleeding-edge developers:
  also banks, online stores, customer service departments,
  governments, and others we can't think of yet).

  But the thing that would it even more useful would be if the same
  body that coordinated the basic format also supplied some useful,
  central, extensions. Many sophisticated uses of Atom (as feed) will
  need more than the core. If /some/ of those can use centralised
  extensions written by the Atom folk, and need nothing else, then
  those uses have more chance of working with off-the-shelf Atom
  clients, or at the least of interoperating straight off.

  If I have to download a custom app for tracking purchases on my VISA
  card, and another for tracking purchases on my Amazon.com account,
  then we've missed a big trick. If they develop their own methods,
  they probably won't directly interoperate (I'm guessing, but I
  imagine that getting Barclays and AmEx to develop a format between
  the two of them would take ages, if it ever happened; Amazon is a
  different matter, but there only needs to be one use different to
  have lost). True, each new use could be a plugin to an existing
  client - but MyFavouriteClient may not be included, and the format
  for the ShinyAllianceExtension may not be public, so I can't even
  write support myself.

  We don't need to do all this at once. Atom-as-feed only needs to get
  the basic model sufficiently right that lots of future uses will fit
  within that model; it also needs to provide an extensibility
  mechanism [1]. Later we can write the UpsellExtension, or the
  AccountPurchasesExtension. Hopefully, some other people will appear
  and produce their own public extensions, or feed them through the
  Atom project to gain more widespread use.


  This is from the point of view of Atom-as-feed. The other
  possibilities will have similar issues (some are considerably harder
  than feed). Again, however, we don't need to do all of them at
  once. Perhaps the question should be more temperate: not "What is
  Atom?", but "What does Atom need to be now so that when we change
  our minds we don't have to start again?".

[1] There's been discussion of extensibility recently that says we'll
get all the extensibility we need by using XML namespaces. Providing
this is documented as the way to do it (so clients don't break on
finding extensions they don't understand - should they drop the enty,
drop the extensions ... ?), this is fine. However there are still
comments on the Wiki from people who hate the idea of
namespaces. Maybe they're out of date. Maybe they should just be
ignored. Maybe we need a different mechanism.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@xxxxxxxxxxxx                               uncertaintydivision.org