Competing Standards and DataPortability? - Compiled from Skype Chat

[Jacob Chapel]

**Any discussion in the Skype chat rooms are potential big topics of
discussion and will be compiled into a discussion post like this. Some
text was removed for being off topic or not relavent to the
discussion. Complete transcripts are available on request. If you
haven't joined the Implementation Skype chat room yet join here:
http://snipr.com/dp_implement_skype

This discussion is about the different standards that are out there
and which we should support or include.

Julian Bond: Atom vs RSS. Where does FOAF sit? Relationships with
OpenSocial Data APis and Twitter APIs. Are these questions that should
be discussed here? Or somewhere else?

Paul: they are definitely questions to speak about here

Julian Bond: Just wasn't sure if that sort of thing sits in the
technical Blueprint group or here.

Paul: the bigger question may also be which way to proceed with them -
accepting multiples, or going down the lines of specifics. I think
they are important to both. perhaps it may be better in the blueprint
group

Jacob Chapel: I think the blueprint group should definitely liaison
with us at least on choices, as we will be the ones using them.

Julian Bond: Take one then. Google is likely to be a big player in
this. They push Atom heavily. It seems likely that the OS Data APIs
will be built on top of Atom. So it feels dangerous to say that RSS is
preferred. If that's what's being said.
http://groups.google.com/group/dataportability-public/web/standards-communities
and in the FAQ.
http://groups.google.com/group/dataportability-public/web/faq#9

Jacob Chapel: though, on the backend, atom/rss are easily accounted
for, so as long as the developer chooses to support both, I see no
reason not to have both be apart of the standards

Paul: thats what makes it a very complicated starting point I think

Jacob Chapel: I dont think we are at a point, dp that is, to be saying
what standard is better

Paul: sure, but we can't just go down a neutral line the whole time.
it makes it impossible to actually get anything done

Jacob Chapel: well no, but we aren't creating standards. we are
defining a complete solution using standards

Paul: which would probably imply the need to select some standards

Jacob Chapel: so why not have alternative options, that at least in
part give the developer the choice

Paul: it makes interoperability very hard that way

Julian Bond: One real world example. I grab feeds from several Twitter
like systems. Jaiku stands apart because they use Atom and they don't
mush the author into the main description field. This makes their feed
hard to merge with that from other systems because without parsing all
the Atom tags out, you lose information. In this case Atom is a more
complete, more descriptive feed. But in the process it's harder to
work with.

Jacob Chapel: My though is that to claim to be DP, you have to follow
the DP specs, but that doesn't mean you cant use alternatives on top
for things like opensocial

Paul: on top is very different to "instead of" atom and rss don't
stack - they sit side by side

Jacob Chapel: Yeah, your real world example gave me the information I
needed :)

Paul: saying that both are supported requires every implementation to
support both

Jacob Chapel: you see though, this is the stuff that needs to be heard
in blueprinting. cant let the politics of standards matter as much as
the functionality and how they are used, is there anyone from google
active in the discussion?

Julian Bond: I think there's a meta level here as well. DP is not just
use this standard, it's also use this standard in this way. We have
this with FOAF in a big way. it's RDF so people overload it with lots
of extra RDF stuff and RDF styles. But there's one big use case
(exporting one peson and their list of friends) which is more like an
etiquette (scheme) on top of the FOAF standard.