2019-06-07-action2: test if `@prefix: false` without `@id` works as expected (Pierre-Antoine Champin)

[iherman]

test if @prefix: false without @id works as expected (Pierre-Antoine Champin) (see details)

Cc: @pchampin

[pchampin]

TL;DR: it doesn't work, and making it work would involve heavy changes in the spec

Current state of the spec

First: when @prefix is false, @id is mandatory (and would still be with the addition proposed in w3c/json-ld-api#76, for that matter).

Second, making @id optional in this situation would not make much sense, because currently @prefix is only used for compaction, not for expansion.

It means that

{
  "@context": {
    "@version": 1.1,
    "foo": {
      "@id": "http://example.org/foo",
      "@prefix": false
    }
  },
  "foo:bar": "baz"
}

expands to

[
  {
    "http://example.org/foobar": [
      {
        "@value": "baz"
      }
    ]
  }
]

(try it in the playground)

The compaction algorithm find a term definition for foo and expands foo:bar as a compact IRI, regardless of the presence of "@prefix": false in its term definition.

In my opinion, there are two distinct things that need to be discussed.

1. Should we change the semantics of @prefix, so that compaction also takes it into account?

After this change, the example above would expand to

[
  {
    "foo:bar": [
      {
        "@value": "baz"
      }
    ]
  }
]

(i.e. foo:bar would be considered as an absolute IRI)

On the one hand, I think this would be globally more consistent and easier to understand for users.

On the other hand, I don't know how deep the implications of that change would be (but I suspect that a can of worms lies there).

2. Do we want to solve w3c/json-ld-syntax#177 with @prefix?

If we answer "yes" to the previous question, then it could make sense to allow a term definition of the form "mailto": { "@prefix": false } or "mailto": { "@prefix": false, "@id": null }. This would prevent the use of the given term either as a prefix or as a vocabulary term.

However, as we have pointed out during the meeting, robustly "protecting" an IRI scheme that way is trickier than it looks, because of the complex interactions between the different kinds of scoped contexts and @protected. So users may use the "@prefix": false feature and think they are safe, while actually they are not.

Also, I found out another problem (w3c/json-ld-api#104) that arise from the ambiguity between compact IRIs and some absolute IRIs...

So I think we should rather tackle the problem at the root, and add a way to express an absolute IRI and make it clear that it is not a compact IRI. This could be done in the line of "Proposed solution 3" at w3c/json-ld-api#104.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

2019-06-07-action2: test if @prefix: false without @id works as expected (Pierre-Antoine Champin) #87
Benjamin Young: issue #87 #87
Benjamin Young: born from #76 w3c/json-ld-api#76
Ivan Herman: original-original: w3c/json-ld-syntax#177
Benjamin Young: next two issues are related
Pierre-Antoine Champin: some background: it was possible to define certain URI schemes as prefixes
… leading to confusing them with the start of CURIs
… I tried to alter @prefix to avoid this
… but that turns out not to be possible
… . so @prefix must be accompanied by @id
… even if you accept ruben’s alteration, it is still not simple
… @prefix is only used during compaction as a hint to the algo
… but never it is used in expansion
… to block interpretation as a CURI
… so doing this with @prefix would radically change the meaning of @prefix, to add an effect during expansion
… this thing will come back and bite other people than us
Adam Soroka: .. users would expect @prefix to work both ways
Pierre-Antoine Champin: but that may have real effects on implementors
Gregg Kellogg: yes, @prefixis only meaningful during compaction
… in 1.0 any prefix could be used
… so we made some changes
… including restrictions and a keyword @prefix to overcome them
… we do run into 1.0 compatibility issues here
… but this is something we just didn’t complete
… it’s not a major rewrite
… now we are forcing the use of expanded term defns for things that used to be simple prefixes
Dave Longley: +1 to what gregg is saying … it seems to mostly be restricted to very local change in IRI expansion where we need one extra flag check
Gregg Kellogg: the impact isn’t too bad on the algos
… we did make changes to limit the use of prefixes during compaction, we should make the same changes for expansion
Ivan Herman: I thikn this issue arose in a different ticket ^^^^
… I have said before that we shouldn’t add too many things to the spec
… do we really have to do anything about #177?
… does it occur significantly in 1.0 usage?
… do we need to spend two meetings on it?
… i don’t think so. my feeling is that we should either close or defer
… we struggled whether this is really a security issue
… it can be awkward
… in several years it did not bite us
Benjamin Young: we haven’t had @prefix very long either!
Ivan Herman: but it’s not a matter of just @prefix
Pierre-Antoine Champin: I agree with ivan
… I’m not convinced that this is a security issue
… . I’m not convinced that @prefix would be a good way to solve it if it were
Adam Soroka: .. getting this right with @prefix would be challenging
Pierre-Antoine Champin: @prefix was introduced for other reasons
… the way we have it now is counterintuitive
… we were all talking last week about using it this way without even realizing we couldn’t. that’s not good!
Gregg Kellogg: when we introduced the restrictions for prefixes, we overlooked expansion
… we left the job partly done
Ivan Herman: we are adding features and making the spec more complicated
Gregg Kellogg: is inconsistency complicated?
Ivan Herman: we are complicating the spec a few months before we try to get to CR
Dave Longley: I sympathize with ivan
… if we consider this a security issue, then @prefix is not how we should address it
… we could instead introduce a rule that you don’t expand prefixes when @vocab = true
Gregg Kellogg: I agree with dlongley; that would solve the problem but burn all the fields
Ivan Herman: I propose that we defer one of the two
Gregg Kellogg: I don’t think we can roll back prefix
… it fixes actual errors in 1.0
Pierre-Antoine Champin: I suggest we make no decision before the next agenda item
Gregg Kellogg: I can do a speculative PR
Benjamin Young: let’s go to the next issue, discuss, then come back to this