Compact API first expands without provided context

[gkellogg]

The Compact API first expands the input document, which is fine. However, even though it's not called out in the spec, the test require (AFIKR) that the document be expanded without using the provided context. The context is only used for compacting the document.

The problem comes when non-JSON-LD documents are passed through the algorithm where the context was provided via a Link header. This would require first a call to expand with the provided context, and then a call to compact with a newly provided context, which would also attempt to expand the incoming document.

Two ways to potentially deal with this:

1. When compacting, always expand the document using the provided context. This could lead to odd problems if the contexts are not aligned.
2. Provide a flag to skip the expansion phase when compacting. (I hate flags, though)
3. Detect if the incoming document does not have a @context and skip the expansion phase. This might yield the best results, since a document can be expanded first using a context from the LInk header, and then compacted without repeating the relatively expensive expansion.

[lanthaler]

We could also just change the parameters to include an expansionContext and a compactionContext. The expansion context would be passed to the expansion call whereas the compactionContext would be the current context.

[lanthaler]

PROPOSAL: Change the compaction API signature from compact(input, context, callback, options) to compact (input, inContext, outContext, callback, options)

This would imply that the context parameter in all other methods should be renamed to inContext as well.

[lanthaler]

Lately I have also been thinking about combining the compact()/expand() methods and controlling their output solely via the parameters. We could even call it frame() for the time being:

Compaction:  frame(input, inContext, outContext, callback, options)
Expansion:   frame(input, inContext, null, callback, options)

This might even eliminate the need for the flattening flag. We could instead use a frame like

{
   "@context": {  ... context used in compaction ... },
   "@id": {}    <-- include all nodes with an ID at the top-level
}

An empty frame or null would invoke expansion; a frame consisting of just a context would invoke compaction, and the only other mechanism currently supported would be to filter for nodes by including the "@id": {} "filter".

This would also keep us the door open to enhance framing quite easily in the future.

[dlongley]

I'm -1 on this. It seems like we're just making the API more cumbersome. Most, if not all, of the API methods already first expand the input before acting on it. Requiring an additional context -- just to handle the single case where one was only provided via a link header -- causes the API to be more complex for every other case (where I believe the other cases are more common).

If you need to expand your input in some other way (eg: because the context came in via a link header), then do that before making the other API calls you want to make. I don't think that's unreasonable -- and I think it keeps the API simple.

[lanthaler]

RESOLVED: Move the optional expansion context parameter in the .expand() call into the last JsonLdOptions parameter.

[lanthaler]

RESOLVED: Process the 'expandContext' option when performing .compact(). When expanding during the .compact() call, the 'expandContext' is applied first, followed with any other contexts held in the document being processed.