Closed iherman closed 5 years ago
This issue was discussed in a meeting.
RESOLVED: Keep #37 open for @omit-graph
I'm not sure @omitGraph
would be particularly useful, as it is only useful at the very top-level and the algorithm doesn't consider it as a possible default when processing a frame object.
Note that it defaults to true
in 1.1, which is probably what most people want. Adding it to the frame is kind of odd, though.
True. But I guess it would require more explanation to describe why this (or other) API flag does not have a keyword equivalent... Furthermore, by using this keyword (and others) the creator of a frame ensures that this statement is always there, regardless of how a particular JSON-LD processor is invoked, ie, how the API flags are set...
See #41, which would remove @omitDefault
while possibly keeping the flag.
In the case of the omit graph flag, it is never encountered when processing a frame, and it would require something extra to reach into the frame to see if this had been set. The default in 1.1 is to omit it, and the flag mostly exists to be able to explicitly go back to the 1.0 behavior.
So we can close?
Closed by resolution: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-29-json-ld#resolution4
This issue was discussed in a meeting.
RESOLVED: Close #37, only edge edge cases when there is disparity
Why isn't there a keyword for all options systematically? There is
@embed
,@explicit
(although I am not sure its choice is the best, but that is bike shedding), but there isn't any@omit-default
,@omit-graph
,@require-all
.I think the reason may be that if, say,
requireAll
is an API flag, then it is global and not per frame. However, if that is the reason, the question becomes: why can't those flags be frame specific?