Moving Activity Vocabulary to IG, minimize AS2.0 Core? [was Re: Clarify objections to JSON [was Re: Getting the group back on track]]

On 10/19/2015 05:12 PM, James M Snell wrote:
> 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.

I think the simplest idea might be to drastically simplify AS2.0 even
more so that it fits the KISS principle, and put the Activity Vocabulary
into an IG note. That was the original plan in the charter. The
reasoning is that discussions about metadata, despite being interesting,
can last forever and will likely change.

Would there be any objections to this?
>>
> 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 Tuesday, 20 October 2015 21:46:38 UTC