I'm almost at a stopping point with my proposed specs. One thing I'm struggling with right now is the decision to include two XML response formats: Atom, and a custom XML vocabulary. Atom suits all of Pownce's needs when it comes to getting and posting notes:
- <atom:content> can contain XHTML, in which we can easily encode all Pownce-specific metadata (including the use of microformats for user and event info) - REST defines the mechanism for posting: POST <atom:entry> elements, PUT/POST file uploads, use <atom:link> to tie them together - the Atom Publishing Protocol allows us to make endpoints discoverable
What Atom doesn't address for us is user information endpoints, lists of friends, and sets. Going the APP collection route also requires a lot more maintenance on our end, and I'm not sure that many people will use it.
What we gain from having a custom XML response format is conciseness and a uniform interface across all endpoints. However, maintaining both the XML and Atom formats also requires additional maintenance, and risks the chance that one will become an orphan used by very few people.
I'm leaning toward a hybrid at this point. I really like Atom, and it fulfills about 90% of our requirements–the rest I can fill in with namespaced XML. I'm also open to the idea of keeping some namespaced XML in the Atom feeds if it turns out that there's information that we need to publish that isn't covered by Atom.
So, the question is: what would you use? If Atom were the only game in town for note publishing, would you scoff at the idea of having to build up <atom:content> blocks that defined required information in XHTML? Or would you prefer to use the Pownce-specific XML vocabulary because it would (presumably) be easier to parse and generate?
Thanks, -- Shawn Allen sh...@stamen.com +1 415 558 1610
I'm all for using Atom as much as possible - it would make the 90% of the data very easy to munge.
The remaining bits (sets, lists of friends, etc) sound like information that can be retrieved as needed by special case endpoints as they don't fall into the "normal" data flow.
So for me: Atom for all posts and something simple for the rest - it doesn't even have to be XML (but I figure that's a long-shot request :)
> I'm all for using Atom as much as possible - it would make the 90% of > the data very easy to munge.
> The remaining bits (sets, lists of friends, etc) sound like > information that can be retrieved as needed by special case endpoints > as they don't fall into the "normal" data flow.
> So for me: Atom for all posts and something simple for the rest - it > doesn't even have to be XML (but I figure that's a long-shot > request :)
> > I'm all for using Atom as much as possible - it would make the 90% of > > the data very easy to munge.
> > The remaining bits (sets, lists of friends, etc) sound like > > information that can be retrieved as needed by special case endpoints > > as they don't fall into the "normal" data flow.
> > So for me: Atom for all posts and something simple for the rest - it > > doesn't even have to be XML (but I figure that's a long-shot > > request :)
I'd love to echo the sentiment for multiple response formats based off a flag in the query. While an RSS or Atom DTD might be interesting, it seems like you would end up shoehorning data into it in almost no time at all. Custom XML is probably your safest bet if you end up going for a single format.
That being said, my personal preference would be JSON, as I can easily see uses of the system where it would be ideal to keep the added weight of a full scale parser out of an application if possible (flash widgets/google gadgets, embedded mobile platforms, rich media banners) not to mention it's just bloody simple to work with.
> I'm almost at a stopping point with my proposed specs. One thing I'm > struggling with right now is the decision to include two XML response > formats: Atom, and a custom XML vocabulary. Atom suits all of > Pownce's needs when it comes to getting and posting notes:
> - <atom:content> can contain XHTML, in which we can easily encode all > Pownce-specific metadata (including the use of microformats for user > and event info) > - REST defines the mechanism for posting: POST <atom:entry> elements, > PUT/POST file uploads, use <atom:link> to tie them together > - the Atom Publishing Protocol allows us to make endpoints discoverable
> What Atom doesn't address for us is user information endpoints, lists > of friends, and sets. Going the APP collection route also requires a > lot more maintenance on our end, and I'm not sure that many people > will use it.
> What we gain from having a custom XML response format is conciseness > and a uniform interface across all endpoints. However, maintaining > both the XML and Atom formats also requires additional maintenance, > and risks the chance that one will become an orphan used by very few > people.
> I'm leaning toward a hybrid at this point. I really like Atom, and it > fulfills about 90% of our requirements-the rest I can fill in with > namespaced XML. I'm also open to the idea of keeping some namespaced > XML in the Atom feeds if it turns out that there's information that > we need to publish that isn't covered by Atom.
> So, the question is: what would you use? If Atom were the only game > in town for note publishing, would you scoff at the idea of having to > build up <atom:content> blocks that defined required information in > XHTML? Or would you prefer to use the Pownce-specific XML vocabulary > because it would (presumably) be easier to parse and generate?
I prefer XML to JSON just because I have so much reusable code at my disposal. What format that XML comes in is almost inconsequential.
One benefit for your platform is that if you use ATOM, it will be easier for newbie mashup developers to use the new tools coming out (Bungee Connect, MS Popfly, OpenKapow, Google Mashup Editor, etc...) to make apps and what nots that use your platform. You'll also not need to spend extra time writing code to present custom feeds for people that just want to subscribe to a URL of notes in an aggregator.
-Mykoleary
On Jul 24, 1:23 pm, Shawn Allen <sh...@stamen.com> wrote:
> I'm almost at a stopping point with my proposed specs. One thing I'm > struggling with right now is the decision to include two XML response > formats: Atom, and a custom XML vocabulary. Atom suits all of > Pownce's needs when it comes to getting and posting notes:
I'm shaky on ATOM, but agree it makes sense. XHTML+uF is great! XFN can also do friends + hCard users + XOXO lists of things. I would say use ATOM where plausible and XOXO as the 'custom XML'
On Jul 24, 4:23 pm, Shawn Allen <sh...@stamen.com> wrote:
> I'm almost at a stopping point with my proposed specs. One thing I'm > struggling with right now is the decision to include two XML response > formats: Atom, and a custom XML vocabulary. Atom suits all of > Pownce's needs when it comes to getting and posting notes:
> - <atom:content> can contain XHTML, in which we can easily encode all > Pownce-specific metadata (including the use of microformats for user > and event info) > - REST defines the mechanism for posting: POST <atom:entry> elements, > PUT/POST file uploads, use <atom:link> to tie them together > - the Atom Publishing Protocol allows us to make endpoints discoverable
> What Atom doesn't address for us is user information endpoints, lists > of friends, and sets. Going the APP collection route also requires a > lot more maintenance on our end, and I'm not sure that many people > will use it.
> What we gain from having a custom XML response format is conciseness > and a uniform interface across all endpoints. However, maintaining > both the XML and Atom formats also requires additional maintenance, > and risks the chance that one will become an orphan used by very few > people.
> I'm leaning toward a hybrid at this point. I really like Atom, and it > fulfills about 90% of our requirements-the rest I can fill in with > namespaced XML. I'm also open to the idea of keeping some namespaced > XML in the Atom feeds if it turns out that there's information that > we need to publish that isn't covered by Atom.
> So, the question is: what would you use? If Atom were the only game > in town for note publishing, would you scoff at the idea of having to > build up <atom:content> blocks that defined required information in > XHTML? Or would you prefer to use the Pownce-specific XML vocabulary > because it would (presumably) be easier to parse and generate?
I also use XML, but I wouldn't want to feel like I couldn't try something with JSON or incorporate features or compatibility with other agents because the support isn't there.
I definitely put my vote on having multiple formats supported. (Hey, because you guys have tons of free time, right?)
On Jul 26, 10:14 am, mykoleary <m...@blueneedle.com> wrote:
> I prefer XML to JSON just because I have so much reusable code at my > disposal. What format that XML comes in is almost inconsequential.
> One benefit for your platform is that if you use ATOM, it will be > easier for newbie mashup developers to use the new tools coming out > (Bungee Connect, MS Popfly, OpenKapow, Google Mashup Editor, etc...) > to make apps and what nots that use your platform. You'll also not > need to spend extra time writing code to present custom feeds for > people that just want to subscribe to a URL of notes in an aggregator.
> -Mykoleary
> On Jul 24, 1:23 pm, Shawn Allen <sh...@stamen.com> wrote:
> > Hey everyone,
> > I'm almost at a stopping point with my proposed specs. One thing I'm > > struggling with right now is the decision to include two XML response > > formats: Atom, and a custom XML vocabulary. Atom suits all of > > Pownce's needs when it comes to getting and posting notes:
> That being said, my personal preference would be JSON, as I can easily > see uses of the system where it would be ideal to keep the added > weight of a full scale parser out of an application if possible (flash > widgets/google gadgets, embedded mobile platforms, rich media banners) > not to mention it's just bloody simple to work with.
>> - REST defines the mechanism for posting: POST <atom:entry> elements,
> Please don't make us POST raw XML -- give it a field name :)
I feel pretty strongly that if we're sending XML (or JSON, or Atom) we should be receiving it as well. JavaScript, for example, is perfectly capable of populating the request body with JSON or XML and setting request headers.
Along with most of the other contributors to this thread, I'd like to see multiple formats supported (in the same way that the Twitter API does) although if you were only to choose one I would definitely plump for an XML response.
> I'm almost at a stopping point with my proposed specs. One thing I'm > struggling with right now is the decision to include two XML response > formats: Atom, and a custom XML vocabulary. Atom suits all of > Pownce's needs when it comes to getting and posting notes:
> - <atom:content> can contain XHTML, in which we can easily encode all > Pownce-specific metadata (including the use of microformats for user > and event info) > - REST defines the mechanism for posting: POST <atom:entry> elements, > PUT/POST file uploads, use <atom:link> to tie them together > - the Atom Publishing Protocol allows us to make endpoints discoverable
> What Atom doesn't address for us is user information endpoints, lists > of friends, and sets. Going the APP collection route also requires a > lot more maintenance on our end, and I'm not sure that many people > will use it.
> What we gain from having a custom XML response format is conciseness > and a uniform interface across all endpoints. However, maintaining > both the XML and Atom formats also requires additional maintenance, > and risks the chance that one will become an orphan used by very few > people.
> I'm leaning toward a hybrid at this point. I really like Atom, and it > fulfills about 90% of our requirements-the rest I can fill in with > namespaced XML. I'm also open to the idea of keeping some namespaced > XML in the Atom feeds if it turns out that there's information that > we need to publish that isn't covered by Atom.
> So, the question is: what would you use? If Atom were the only game > in town for note publishing, would you scoff at the idea of having to > build up <atom:content> blocks that defined required information in > XHTML? Or would you prefer to use the Pownce-specific XML vocabulary > because it would (presumably) be easier to parse and generate?
|
