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

On Mon, Oct 19, 2015 at 2:09 PM, Ben <ben@thatmustbe.me> wrote:
> I agree Harry,
>
> JSON sounds great, AS2 is not just JSON, its a bunch of stuff piled on there.
> Its messy, Its overly complex, and it forgot the KISS principle.
>

Few quick questions:

1. What parts are messy?
2. What parts are overly complex?
3. What parts would you prefer to see removed?

- James

> Would any implementers from other groups be interested in trying something
> based on some extremely simple set of JSON?  Lets see how far we can get
> without getting stuck in arguments of vocabularies and such.
> For example lets just test getting some very very basic functionality such as
>  likes, and maybe comments working across several systems.
>
> On Mon, Oct 19, 2015 at 4:37 PM, Harry Halpin <hhalpin@w3.org> wrote:
>> 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 21:13:40 UTC