Re: AS2 media type

Any "extra work" required for the MIME type registration is actually
quite minimal.

The `application/ld+json` media type carries with it certain
assumptions that simply do not hold with the AS2 serialization and all
of the arguments and warnings of impending doom should we continue
with the use of `application/activity+json` have fallen rather flat in
my opinion. I'm absolutely +1 on maintaining the current status quo
and keeping the application/activity+json media type in place and -1
on dropping it in favor of the more generic media type.

- James

On Tue, Oct 20, 2015 at 8:59 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
[snip]
>
> Thanks James, I think you've raised a number of good points.
>
> Regarding the question as to :
>
> 1. New mime type
> 2. Reuse existing mime type + profile parameter
>
> it would be good to establish how strongly you feel on this issue.  I think
> there are legitimate arguments on both sides.
>
> A new mime type would incur extra work, and would need to go through an
> approval process.  Both the W3C and IANA would need to accept it.  There may
> also need to be a file extension specified.  Granted, there are generally
> low bars for acceptance at iANA.  And there is a precedent for W3C
> publishing work with a JSON serialization that is not JSON LD, namely
> RDF/JSON
>
> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html
>
> Tho perhaps there would need to be some accompanying text to explain to
> readers the relationship with JSON LD.
>
> My thought is that going the JSON LD route + profile parameter incurs no
> extra work from a standardization perspective.  A new mime type would incur
> extra work and it would be good to hear how much of a show stopper this
> issue is before closing it.
>
>>
>>
>> On Tue, Oct 20, 2015 at 6:52 AM, James M Snell <jasnell@gmail.com> wrote:
>> > Elf,
>> >
>> > I've answered your questions about Curie expansion already. I'm not
>> > going to
>> > answer them again.
>> >
>> > Your concerns about as:Link have been brought up previously, discussed,
>> > and
>> > the group decided to keep the current model. I will not be revisiting
>> > that
>> > discussion.
>> >
>> > The discussion over requiring the compact form happened over a year ago.
>> > I
>> > will not be revisiting that discussion either.
>> >
>> > The conversation happening right now is about the media type.
>> >
>> > - James
>> >
>> > On Oct 20, 2015 3:33 AM, "elf Pavlik" <perpetual-tripper@wwelves.org>
>> > wrote:
>> >>
>> >> Hi James,
>> >>
>> >> On 10/20/2015 12:00 AM, James M Snell wrote:
>> >> > On Mon, Oct 19, 2015 at 2:45 PM, Sarven Capadisli <info@csarven.ca>
>> >> > wrote:
>> >> > [snip]
>> >> >>
>> >> >> What breaks when you reuse the existing media types?
>> >> >>
>> >> >> How are the existing media types insufficient to AS2's needs?
>> >> >>
>> >> >
>> >> > Among other things, AS2 requires:
>> >> >   (a) the use of a normative @context definition;
>> >> This requires *all* clients to have 'hard coded' knowledge about
>> >> existence and location of that normative context. Non AS2 specific
>> >> clients will not have possibility to find it, which will limit audience
>> >> of data published this way. IMO using profile parameter seems to work
>> >> for all clients, those who know about AS2.0 specific processing and
>> >> those which will do their best by interpreting i as JSON-LD
>> >>
>> >>
>> >> >   (b) the use of JSON-LD compact form;
>> >> IMO this can cause more interoperability problems than benefits! If
>> >> people don't expand URIs in their code before matching them, this will
>> >> break the whole extensibility. Property with compacted name 'ex:foo'
>> >> from one source, doesn't equal property with the same compacted name
>> >> 'ex:foo' from another source. One still need to expand them to full
>> >> URIs
>> >> based on mappings in ... JSON-LD context.
>> >>
>> >> >   (c) that all date/time values use ISO8601 format
>> >> https://tools.ietf.org/html/rfc7493#section-4.3
>> >>
>> >> >   (d) that the AS1 "objectType" and "id" values MUST NOT be used.
>> >> only relevant to people who migrate from AS1 (anyone even works on
>> >> it?),
>> >> nothing to do with people starting from AS2
>> >>
>> >> >   (e) the implementations MUST treat all objects as derivatives of
>> >> > as:Object unless the the object uses @type:as:Link
>> >> IMO we still have some work to do with all the issues around as:Link ,
>> >> actually it seems more relevant to API than *modeling social
>> >> information*
>> >>
>> >>
>> >> >   (f) that AS defined terms be preferred over overlapping terms from
>> >> > other vocabularies
>> >> overlapping? how come? all AS terms have *unique* URIs to identify
>> >> them,
>> >> no overlap possible... unless we try to make ourselves believe that we
>> >> can have extensibility without expending to full URIs -1
>> >>
>> >>
>> >> >
>> >> > Using "application/ld+json" does not communicate to a receiver any of
>> >> > these additional constraints.
>> >> >
>> >> > Which means in order to communicate these additional constraints, a
>> >> > profile parameter would need to be used, in which case you've
>> >> > accomplished nothing more than you would by simply defining a new
>> >> > media type.
>> >> Again, non AS2.0 specific clients will not have a way to process data,
>> >> even that 'behind masquerade' it uses JSON-LD which they could process
>> >> easily.
>> >>
>> >>
>> >> >
>> >> > - James
>> >>
>> >> I apologies if I sound impatient in this email, I just have impression
>> >> that after a year of working on it 'kind of together' we keep walking
>> >> in
>> >> circles :(
>> >>
>> >> Cheers!
>> >>
>> >
>>
>

Received on Tuesday, 20 October 2015 16:14:31 UTC