Re: Getting the group back on track

The short answer is: nothing breaks. Implementations that support the
`application/activity+json` media type will understand that AS 2.0 is
a JSON-LD based syntax and will use JSON-LD mechanisms to process
them. The implementations that intentionally choose not to use JSON-LD
mechanisms to process are given sufficient warning that interop issues
could arise from that decision.

Also,tThere is absolutely nothing stopping an implementation from
using the `application/ld+json` media type when transmitting Activity
Streams 2.0 data if they have good reason to do so. The
`application/activity+json` media type is more specific, yes, but it
*does not break anything*.

Also, quick correction on Melvin's post: the open issue on github is
*not* about changing the media type to `application/activity+json`.
It's about requiring the use of the `application/ld+json` media type
with an additional profile parameter. I've seen absolutely no reason
to require the `application/ld+json` media type and after implementing
AS 2.0 support in a few applications, I see absolutely nothing that
breaks or doesn't work by using the `application/activity+json` media
type.

I'd very much like to just put the whole media type issue to rest as
it really is a red herring. I've heard many times that it "breaks"
things without seeing any actual evidence that things actually do get
broken.

- James

On Wed, Oct 14, 2015 at 8:28 AM, elf Pavlik
<perpetual-tripper@wwelves.org> wrote:
[snip]
>>
>> Can you point to what tooling breaks?
>>
>> The larger issue with some of the RDF-centric approaches is that while
>> we can recommend Link HTTP headers and MIME types, most tooling that I
>> know of ignores both of these, and would also not expand JSON-LD (since
>> most tooling is JSON-centric)
>
> Systems which integrate AS2.0 data from multiple sources need at minimum
> expand CURIEs to distinguish properties using full URIs
>
> http://www.w3.org/TR/activitystreams-core/#aggregation-of-extensions
>
> Also our charter says:
>
> "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."
>
>
>

Received on Wednesday, 14 October 2015 15:46:59 UTC