Re: Clarify objections to JSON [was Re: Getting the group back on track]

Harry Halpin writes:

> 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

+1k to all this

Received on Monday, 19 October 2015 21:54:45 UTC