JsonLdOptions base vs. @base #223

Closed
lanthaler opened this Issue Mar 1, 2013 · 22 comments

Projects

None yet

5 participants

@lanthaler
Member

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

@lanthaler
Member

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
Member

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).

@lanthaler lanthaler added a commit that referenced this issue Mar 5, 2013
@lanthaler lanthaler Allows IRI references (such as "") to be used in @base.
This addresses #223.
5043f80
@lanthaler lanthaler added a commit that referenced this issue Mar 5, 2013
@lanthaler lanthaler Add test for "@base": ""
This addresses #223.
133194a
@lanthaler lanthaler added a commit that referenced this issue Mar 6, 2013
@lanthaler lanthaler Fix expand-0062
The algorithm in http://tools.ietf.org/html/rfc3986#section-5.2.2 produces different results for IRI references starting with "../" etc.

@dlongley, let me know if you disagree.

This addresses #223.
f18a3f5
@dlongley
Member
dlongley commented Mar 6, 2013

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
Member
dlongley commented Mar 6, 2013

PROPOSAL 1: +1
PROPOSAL 2: +1

@msporny
Member
msporny commented Mar 6, 2013

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

@lanthaler
Member

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
Member

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
Member
dlongley commented Mar 6, 2013

PROPOSAL 3: -1
PROPOSAL 4: +1

@gkellogg
Member
gkellogg commented Mar 6, 2013

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

@lanthaler
Member

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
Member
msporny commented Mar 7, 2013

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.

@dlongley
Member
dlongley commented Mar 7, 2013

I don't think @base should be a relative IRI (I didn't think that was even being considered). It should be an absolute IRI, the empty string, or null. If an author wants to lock base to "none" they can do that. If a developer wants to apply a base to such a document, they can compact to a new context.

@lanthaler
Member

Well, the empty string is also a valid relative IRI.

In my opinion the cleanest solution is still to do this things at the API level. Introducing this special behavior for the empty string is inconsistent with almost everything else (HTML, XML, Turtle, etc.)

I’m not even sure I understand what use case we are trying to address with @base: "".

@niklasl
Member
niklasl commented Mar 8, 2013

PROPOSAL 3: +1

I agree with Markus; I believe other formats would treat @base: "" as a relative reference (i.e. use externally provided base). Intuitively, I would expect setting it to either that or null to have the same effect: just clearing any @base from an inherited context.

A document using relative IRIs in references is effectively yielding control of their resolution to the parser/user of that document (who should of course adhere to the rules of HTTP publishing for resolving relative references in so-retrieved documents). If you don't want that, use full, absolute IRIs in the references.

@lanthaler lanthaler added a commit that referenced this issue Mar 13, 2013
@lanthaler lanthaler Some minor fixes and improvements to Grammar
Mostly things were reordered. There were two notable changes:

I made was to rename "expanded value" to "value object" to be in line with the API spec. I also introduced the notion of "list object" and "set object" instead of just calling them sets and lists (defined in the data model).

I changed the value space of @base to the be an absolute IRI or null (before it also included relative IRIs) (see also #223).
147f8de
@lanthaler lanthaler added a commit that referenced this issue Mar 14, 2013
@lanthaler lanthaler Minor improvements of the Context Processing Algorithms
The only change was to disallow relative base IRIs. The test suite has been updated accordingly.

This addresses #218 and #223.
923c9b6
@lanthaler lanthaler added a commit that referenced this issue Mar 22, 2013
@lanthaler lanthaler Use relative IRI resolution and not IRI Expansion for remote contexts
This means that no compact IRIs, terms, etc. are evaluated when expanding the relative IRI of a remote context. The other change in this commit ensures that, if the remote context doesn't define a base IRI, the "outer" base IRI is kept. I also fixed some references to RFCs.

This addresses #223.
2883c6c
@lanthaler lanthaler added a commit that referenced this issue Mar 26, 2013
@lanthaler lanthaler Make issue marker of @base more informative
@msporny does this address your concerns regarding LC?

This addresses #223
28ff3dc
@lanthaler
Member

Request by Stian Soiland-Reyes to keep base (and to support relative URLs).

@lanthaler
Member

RESOLVED: Support relative IRIs in @base.

@lanthaler
Member

RESOLVED: @base is always resolved against the current documents URL.

@lanthaler
Member

_New Base Resolution Algorithm:_

  initialize base to null
  if document URL exists, initialize base to document URL
  If API option is set, override base with base API option.
  @base overwrites base
  remote context, @base doesn't overwrite base
  @base: null, when used in the local document, sets base to null (no base)
  if you try to set a relative base, and your existing base is null, throw an error.

RESOLVED: Accept the new Base Resolution Algorithm, which supports setting @base: null (no base value).

@lanthaler lanthaler added a commit that referenced this issue May 8, 2013
@lanthaler lanthaler Update processing of base IRI
This addresses #223.
50f6ac3
@lanthaler lanthaler added a commit that referenced this issue May 8, 2013
@lanthaler lanthaler Remove feature at risk marker for @base
This addresses #223
e58f5ff
@lanthaler lanthaler added a commit that referenced this issue May 8, 2013
@lanthaler lanthaler Remove default value of JsonLdOptions base
This addresses #223.
38ae0e9
@lanthaler
Member

I've updated both the syntax and the API spec and will therefore proceed and close this issue in 24 hours unless I hear objections.

@lanthaler lanthaler closed this May 9, 2013
@lanthaler
Member

RESOLVED: Add an issue marker for the "@base": null feature in the JSON-LD API CR specification - it may be modified or removed.

@lanthaler lanthaler reopened this Aug 20, 2013
@lanthaler
Member

RESOLVED: Drop relative IRI in the serialize to RDF algorithm. JSON-LD processors are free to include an option that preserves relative IRIs when serializing to RDF.

@lanthaler lanthaler added a commit that referenced this issue Aug 20, 2013
@lanthaler lanthaler Drop triples containing relative IRIs when converting to RDF
Graph using a relative IRI as graph name are dropped as well.

This addresses #223
d3c8aeb
@lanthaler lanthaler added a commit that referenced this issue Aug 20, 2013
@lanthaler lanthaler Add issue marker for @base: null
This addresses #223
1305320
@lanthaler
Member

Closing this issue as it has been fixed dropping triples containing relative IRIs and adding a feature-at-risk marker to the spec.

@lanthaler lanthaler closed this Oct 10, 2013
@dlongley dlongley referenced this issue in lanthaler/JsonLD Oct 30, 2013
Closed

Bugs with handling @base: null #47

@lanthaler lanthaler pushed a commit to lanthaler/json-ld.org that referenced this issue Jan 13, 2014
@dlongley dlongley Fix test so that @base is set to none (not reset) for @base: null. c24a995
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment