Re: Getting the group back on track

On 14 October 2015 at 17:46, James M Snell <jasnell@gmail.com> wrote:

> 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*.
>

if you're using generic tooling nothing breaks if you use
"application/ld+json", so if you're OK with implementors using this, that
could work

"application/activity+json", adds complexity for generic tooling, and Im
merely asking why the added complexity?


>
> 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."
> >
> >
> >
>
>