Re: AS2 media type

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

If we consider ActivityStreams 2.0 to be continuing the tradition of
Atom, RSS, etc. then I might want to add that all of these formats tend
to have IANA media types.

For example, Atom+XML's IANA registration is here:
http://www.iana.org/assignments/media-types/application/atom+xml

And RSS is here:
http://tools.ietf.org/id/draft-nottingham-rss-media-type-00.txt

Adding a MIME type registration to ActivityStreams 2.0 is the right
thing to do *if* it can be treated by JSON-LD but has significant
differences and may trigger special purpose processing.

In reality, unless there's widespread in-browser treatment of a special
Media type (and neither ActivityStreams nor JSON-LD has any browser
interest and so no special processing), having a new media type will
simply prompt the download of the file - as opposed to well-known media
types.

Regardless, the W3C in general is familiar with registering MIME types
and this should not be a difficulty if required by the WG. On a personal
note, I'm happy to help.

                    cheers,
                     harry


>
> - 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:31:04 UTC