Re: a question about framing test 14

> On 2016-03-30, at 18:42, Dave Longley <dlongley@digitalbazaar.com> wrote:
> 
> On 03/30/2016 12:07 PM, james anderson wrote:
>> good afternoon;
>> 
>>> 
>>> The framing spec is sorely out-of-date and does not include options like
>>> those specified in that issue.
>> 
>> this reads as if one has yet to decide, what the framing algorithm is
>> intended to do.
> 
> That is correct. The behavior has not yet been formally standardized, though most (if not all) implementations currently have the same behavior. It is a work in progress.

that my be a step forward, but it does not seem plausible approach to refer users to several implementations and say, well, try to figure out what they do.

> 
>> 
>> is there some way to understand the comments to that issue as an answer
>> to the question about how nested embedding is to work other than “by
>> default"?
>> i see the options, but the intended effect is not clear.
> 
> You may specify these embed options within your frame or as defaults in the API:
> 
> "@embed": "@always" - For a node that matches the frame filter, every single one of its related nodes will be embedded (or nested) within that node -- and this nesting behavior will recurse through those related nodes until no other related nodes are found or until a cycle is encountered in the graph.

this independent of any type constraint which may have been expressed in a nested frame?


> Note that this may cause data duplication in the output.

why? does this mean it should appear both at all embedded locations and at the top level or at the first embedded location and at the top level, or at all embedded locations and not at the top level?

> 
> "@embed": "@last" - This behavior will match "@always" except that a list of references to previously embedded nodes will be maintained. When a embedding/nesting operation occurs, that list will be checked to see if the related node has already been embedded/nested. If it has, that embedded node is moved to the new location and, at its old location, replaced with only a reference to its subject. In this way, no data duplication occurs and the "last" position the algorithm touches will be where the embed occurs. This is the default embed behavior because it does not change the data.

this would appear to restrict the operation to an in-memory manipulation and would not be feasible for a large stream.

> 
> "@embed": "@never" - This behavior will always cause related nodes to be referenced by their subject only, never embedded/nested.

you mean, to appear as top-level nodes only.
i thought they are always referenced by subject, no matter where they would appear.

> 
> "@embed": "@link" - This behavior will do the same thing that "@always" does, however, without causing any data duplication. Instead, an in-memory reference will be used whenever an embedded/nested node appears more than once.

what dose this mean if the process is to encode the data to a stream rather than to reconstruct an in-memory model.

> This method does not produce an easily serializable document, but is useful for some applications to work with.
> 
> I'll show some examples for how you specify these options in your frame in my response to your other email.

given the number of variations,  a more complete set of example may be necessary.

best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com