- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Wed, 17 Aug 2016 16:52:24 -0700
- To: James Anderson <james@dydra.com>
- Cc: JSON-LD CG <public-linked-json@w3.org>
- Message-Id: <066C0218-C1E9-4445-A96A-6D900BD8DF0C@greggkellogg.net>
> On Aug 17, 2016, at 4:33 PM, james anderson <james@dydra.com> wrote: > > good morning; > >> On 2016-08-17, at 22:43, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote: >> >> […] >>> >>> I don't know if the Ruby implementation supports these features yet. >> >> I believe I support all of the embedding options that Dave’s does. >> >> BTW, on my short-term list is to try to update the Framing spec based on this common behavior. > > > if you should get to that, please distinguish between behaviour which concerns or presumes a json data model and that which concerns just the encoding itself. > as the document stands, there are aspects which one ignores - with bad conscience, but to advantage, when one has no json data model and there are others which, when they are implemented because they are stated so explicitly, but without a model, are just not a good idea. James, I imagine the algorithm to be defined in a manner similar to both the existing, and other JSON-LD algorithms. As framing always involves expansion, the structure of both the frame, and the source document is well defined in terms of expanded JSON-LD. Could you provide an example of where the existing text confuses the JSON data model and the encoding? If this is confusing in existing algorithms, can you suggest how that wording might be improved? Gregg > best regards, from berlin, > --- > james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com <http://dydra.com/> > > > > >
Received on Wednesday, 17 August 2016 23:52:54 UTC