- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 19 May 2015 08:08:37 -0700
- To: Harry Halpin <hhalpin@w3.org>
- Cc: "public-socialweb@w3.org" <public-socialweb@w3.org>
Agreed. Getting the JSON-LD tooling updated would be the ideal approach. https://github.com/digitalbazaar/jsonld.js On Tue, May 19, 2015 at 8:06 AM, Harry Halpin <hhalpin@w3.org> wrote: > > > On 05/19/2015 04:47 PM, James M Snell wrote: >> That could be difficult for implementers using existing json-ld stacks. > > Given existing JSON-LD stacks are still not widely deployed, maybe it > would be a good idea to revise that toolset to be consistent with I-JSON? > > It seems like the right long-term bet, but I'm not sure what the > resourcing level is in current JSON-LD implementations to revise, but I > don't see anything in I-JSON that would break JSON-LD off the top of my > head at a quick glance. > >> On May 19, 2015 7:31 AM, "☮ elf Pavlik ☮" <perpetual-tripper@wwelves.org> >> wrote: >> >>> On 03/23/2015 09:40 AM, Erik Wilde wrote: >>>> hello. >>>> >>>> fyi, there just was a new RFC for JSON. it is called I-JSON and is meant >>>> to be a more restricted subset of JSON ruling out some of the more >>>> obscure things that are legal in JSON, but may lead to strange behavior >>>> and inconsistent interpretation across implementations. >>>> >>>> http://tools.ietf.org/html/rfc7493 >>>> >>>> if we go the plain JSON route, we could say something similar to the >>>> idea of postel's law: AS producers should only produce I-JSON, but they >>>> should be prepared to consume unrestricted JSON. >>>> >>>> cheers, >>>> >>>> dret. >>>> >>> sounds reasonable to me, recommend it in AS2.0 spec as well as for >>> Social API! >>> >> >
Received on Tuesday, 19 May 2015 15:09:26 UTC