- From: Harry Halpin <hhalpin@w3.org>
- Date: Tue, 20 Oct 2015 12:30:59 -0400
- To: public-socialweb@w3.org
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