- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 19 Oct 2015 16:37:43 -0400
- To: Christopher Allan Webber <cwebber@dustycloud.org>, "public-socialweb@w3.org" <public-socialweb@w3.org>
On 10/19/2015 04:11 PM, Christopher Allan Webber wrote: > Ben Werdmüller writes: > >> Folks, >> >> I want to revisit my statement here. I apologize for not being in the >> calls, and I think it's important that my intention isn't mischaracterized. >> >> My intention was: "agree on something, and we will implement it". It was >> not: "we love Activity Streams 2.0". >> >> I wrote a piece the other day about web standards that adds further detail >> to my position ( >> http://stream.withknown.com/2015/a-short-note-about-web-standards-from-your-friends-at). >> It's important, in my opinion, that any standard is: >> >> * Open >> * Easy to implement >> * Agnostic to ideology >> >> This was true of HTML, and it's true (perhaps to a lesser extent) of RSS. >> The cool thing about the web is that you can build something in an hour, >> and I think it was key to its success. It started simple and iterated >> through real-world use, which is how all successful technologies on the web >> are built. Even the img tag, as we all know, was added later. >> Standardization through organic use is powerful. >> >> Known has the indieweb technologies built in, alongside RSS, because >> they're simple, which is why I believe in them (we're about to deploy >> across several university campuses, which will multiply the total userbase >> by a factor of at least 6). They in themselves are iterations on Atom >> primitives. To be clear, I'm not adverse to adding other technologies to >> the mix at all - what I think is important is that the users of a >> decentralized social web are a core part of determining its direction, >> rather than it being dictated in a top-down fashion. >> >> So, to revisit "agree on something, and we will implement it", for what >> it's worth, I'd prefer it was a lightweight starting point that the web can >> iterate on. >> >> Ben > Ben, I agree with this and would like to see it happen. > > Getting any sort of agreement seems to be the hard part, now... Why can't we get agreement on JSON? Again, without a common transport protocol (HTTP) and a common messaging format (JSON), we will just be developing decentralized silos, i.e. IndieWeb sites not talking to RDF-using sites not talking to ActivityPump/Media Goblin. Sigh. To add in a dose of realism, JSON is what modern programming languages (Go, Ruby, etc.) use by default and 99% of developers. The JSON-using development community is *orders of magnitude* larger than both the RDF/Linked Data community and the microformat community. I think both RDF and microformats have done tremendous activity in this space and should be recognized and real work should be made to guarantee interop with microformats and RDF. However, the burden of development 'shims' (relatively easy in both cases due to mf2 and JSON-LD) should be on those communities, who should recognize that while they are innovative, a common interop language will end up being JSON. "Shims" that MAY consume RDF and Microformats probably should be specified by the API, i.e. what to do when your API encounters non-JSON, but the default assumption should be JSON. In my personal opinion, ActivityStreams2 simply should help be the JSON 'successor' syntax to RSS and Atom. The problem with AS1 and even *moreso* with AS2 is lack of implementers and interest. However, it seems we have a number of open source projects and a small amount of vendors willing to commit to it. On the other hand, it probably needs more implementation feedback before going to CR (i.e. a 'Last Call' phase). In general, making it more minimal is probably a good thing. Indeed, if one made something simpler than AS2 and it was JSON-based, it would be within charter. Second, it's in the charter that I wrote, i.e. "A transfer syntax for social data such as activities (such as status updates) should include at least the ability to describe the data using URIs in an extensible manner, time-stamping, and should include a serialization compatible with Javascript (JSON) and possibly JSON-LD. Formats based on XML or other data serializations are out-of-scope. " If you don't agree with the charter, the wonderful thing about standards bodies is there's so many to choose from: One can always go somewhere else. Or we can simply ask W3C to write a new charter, in which case we should do so sooner rather than later if there *really* isn't any support for JSON. I'd suggest that folks who want to block progress on going forward with JSON sit back and think why they are in the Working Group: Remember that simply adding 'W3C' to a spec does not necessarily increase adoption. Examples such as SOAP abound. The *core* problem with AS2 is that it did not have much developer interest *before* launching the Working Group (ideally, we should see lots of implementation before standardizing), and the theory was that the WG would help increase developer implementations. This finally appears to be happening. There's larger problems than AS2 we have to face, i.e. an API (likely simple is good) and federation (hard), so I suspect we should stop bike-shedding on this one. I'd like to invite all folks who objected to AS2 to explain how they will gain interop without a common messaging format (or why their format clearly has more take-up than JSON). If a sufficient case isn't made, we should continue forward with JSON or end the Working Group via closing/re-chartering. So let's stop bike-shedding and get to the hard work! cheers, harry
Received on Monday, 19 October 2015 20:37:46 UTC