JsonLdOptions base vs. @base

[lanthaler]

We should clarify how they work together and perhaps drop one or the other.

[lanthaler]

RESOLVED: 'base' (passed in via the API) sets the document base, @base (in the document) overrides any value set by 'base' (passed in via the API).

[lanthaler]

RESOLVED: Allow @base to be set to the empty string. If @base is set to the empty string, relative IRIs are processed according to RFC 3986 Section 5.2.2 (which is how they're always processed in JSON-LD).

[dlongley]

PROPOSAL 1: If the 'active base' is set to the empty string, relative IRIs are processed according to RFC 3986 Section 5.2.2, with the exception that leading './' and '../' are preserved.

PROPOSAL 2: If the 'active base' is set to the empty string, no IRI processing is performed on relative IRIs.

[dlongley]

PROPOSAL 1: +1
PROPOSAL 2: +1

[msporny]

PROPOSAL 1: -1 (we shouldn't create a new, non-standard way of processing relative IRIs)
PROPOSAL 2: +1

[lanthaler]

The problem is not so easy.. what if the base is set to “../”? What if it is set to “something”? Whatever we do, we will end up creating a non-standard way of processing relative-IRIs.

PROPOSAL 3: The value of @base must be an absolute IRI. If relative IRIs should remain relative IRIs the base option should be set to null.

PROPOSAL 4: The value of @base MUST be null, an absolute IRI or an empty string. The empty string represents the value “no base IRI” whereas null resets it and falls back to the base established according RFC3986. If no base IRI can be established, relative IRIs are not processed. (basically the same as PROPOSAL 2 but a bit more explicit)

[lanthaler]

PROPOSAL 1: -1
PROPOSAL 2: -0.5
PROPOSAL 3: +1
PROPOSAL 4: -0.5

Setting base to “no base“ from within a document doesn’t make much sense in my opinion. You should do that via an API flag (which we already have).

[dlongley]

PROPOSAL 3: -1
PROPOSAL 4: +1

[gkellogg]

PROPOSAL 1: -1
PROPOSAL 2: +0.5
PROPOSAL 3: -0.1
PROPOSAL 4: +1

[lanthaler]

Sorry to insist on this, but I think you don’t fully understand the consequences of what you are proposing (at least I didn’t at the beginning).

If you set the base to “no base” in your context, a client will not be able to automatically expand relative IRIs to absolutes, ever. The only way to achieve that is to pre-process the whole document and replace all values of @base that are not absolute IRIs with absolute IRIs or null... and even that might not be enough as there could still be an external context you don’t have control over. So effectively a client would need to expand the relative IRIs itself.

Can you please elaborate on why PROPOSAL 3 is not an option for you?

It is very explicit, makes publishers’ life just slightly more difficult (does it really?), and hides all the complexity from clients. Furthermore we would not be inventing something new.

The alternative would be to expand @base against the application-dependent base, so effectively setting it to the empty string would have the same effect as setting it to null. This is what browsers do.

[msporny]

PROPOSAL 3: +0.8 (It seems like the empty string might be more clear than 'null', which usually means 'not defined/undefine it in JSON-LD)
PROPOSAL 4: +1

If you set the base to “no base” in your context, a client will not be able to automatically expand relative IRIs to absolutes, ever. The only way to achieve that is to pre-process the whole document and replace all values of @base that are not absolute IRIs with absolute IRIs or null... and even that might not be enough as there could still be an external context you don’t have control over. So effectively a client would need to expand the relative IRIs itself.

Yep, in general, the author of the document has the final say about what the document expresses. We could say that a base given via the API takes precedence over the @base in the document, but that would lead to more problems, IMHO. For example, what happens if I just set the document location as the API base in my processor for all documents processed? That would make my processor override everybody elses @base value, which would be the wrong thing to do. It's the same problem, but in reverse, now the document author has no way of stating very explicitly what the @base should be.

Can you please elaborate on why PROPOSAL 3 is not an option for you?

@gkellogg @dlongley I agree with Markus - the JSON-LD syntax shouldn't allow the @base IRI to be a relative IRI, that goes against RFC 3986:

A base URI must be established by the parser prior to parsing URI references that might be relative. A base URI must conform to the syntax rule (Section 4.3). -- http://tools.ietf.org/html/rfc3986#section-5.1

The alternative would be to expand @base against the application-dependent base, so effectively setting it to the empty string would have the same effect as setting it to null. This is what browsers do.

We could do this, but I prefer just limiting the value of @base to be null, the empty string, or an absolute IRI.