Re: AS2 media type

On 20 October 2015 at 18:13, James M Snell <jasnell@gmail.com> wrote:

> 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, thanks for making your position clear.

I also agree that predictions and warnings of doom are unproductive.
Perhaps we can try and weigh the pros and cons while avoiding hyperbole.
It would also be helpful to try and avoid sweeping generalizations and
definitive predictions on things that are still potentially unclear.  The
XG made this mistake in backing OStatus 5 years ago, and it didnt received
gain the adoption that many hoped.

But it does seem to me that there are good arguments on both sides here.

What seems clear is that reusing the existing mime type with a profile
parameter is something no one could object to, as it is already
standardized.

There would be some administrative and approval burden associated with
creating a new JSON serialization, with the WG, the W3C and IETF.  It could
be argued that these are procedural and trivial hurdles, but it could also
be argued that they are risks and unknowns.  Whichever is the case, they
exist.

I think the case on both sides has not yet been fully made.  As I
understand it the goal from the start was a relatively simple syntax that
is predicted to be developer friendly.  It's unclear to me at least the
extent of this, given that there are existing libraries for JSON LD and if
AS diverges from that, more code may need to be written.  In any case, I
can see the argument.

Another point is that there is a perception that the JSON LD mime type is
not in use, and the arguments for it are based on theory and not adoption.
I also think this may be not fully appreciated.  JSON LD, while new, has
gained adoption, and it is growing.  To name a few schema.org, google, BBC
use it and it's also leveraged in W3C standards such as LDP, web payments
and others.

I think in general, the burden of proof lies less with the strategy of
reuse, and more with the strategy of proposing something new, when creating
a standard.  I am at least partially convinced by your recent points, but I
think this one is important enough to keep open.


>
> - 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!
> >> >>
> >> >
> >>
> >
>