Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

JsonLdOptions base vs. @base #223

Closed
lanthaler opened this Issue · 22 comments

5 participants

@lanthaler
Owner

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

@lanthaler
Owner

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
Owner

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 referenced this issue from a commit
@lanthaler lanthaler Add test for "@base": ""
This addresses #223.
133194a
@lanthaler lanthaler referenced this issue from a commit
@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
Owner

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
Owner

PROPOSAL 1: +1
PROPOSAL 2: +1

@msporny
Owner

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

@lanthaler
Owner
@lanthaler
Owner
@dlongley
Owner

PROPOSAL 3: -1
PROPOSAL 4: +1

@gkellogg
Owner

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

@lanthaler
Owner
@msporny
Owner

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
Owner

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
Owner
@niklasl
Collaborator

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 referenced this issue from a commit
@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 referenced this issue from a commit
@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 referenced this issue from a commit
@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 referenced this issue from a commit
@lanthaler lanthaler Make issue marker of @base more informative
@msporny does this address your concerns regarding LC?

This addresses #223
28ff3dc
@lanthaler
Owner

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

@lanthaler
Owner

RESOLVED: Support relative IRIs in @base.

@lanthaler
Owner

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

@lanthaler
Owner

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 referenced this issue from a commit
@lanthaler lanthaler Update processing of base IRI
This addresses #223.
50f6ac3
@lanthaler lanthaler referenced this issue from a commit
@lanthaler lanthaler Remove feature at risk marker for @base
This addresses #223
e58f5ff
@lanthaler lanthaler referenced this issue from a commit
@lanthaler lanthaler Remove default value of JsonLdOptions base
This addresses #223.
38ae0e9
@lanthaler
Owner

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
@lanthaler
Owner

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
@lanthaler
Owner

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 referenced this issue from a commit
@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 referenced this issue from a commit
@lanthaler lanthaler Add issue marker for @base: null
This addresses #223
1305320
@lanthaler
Owner

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
@dlongley dlongley referenced this issue in lanthaler/JsonLD
Closed

Bugs with handling @base: null #47

@lanthaler lanthaler referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.