Section 2.2 on IRIs and URLs in activitystreams-core incorrectly references URLs in JSON being a problem

[ThisIsMissEm]

The current text is:

Relative IRI (and URL) references SHOULD NOT be used within an Activity Streams 2.0 document due to the fact that many JSON parser implementations are not capable of reliably preserving the base context necessary to properly resolve relative references.

However, JSON doesn't do anything at all with URLs and IRIs, to JSON they are just strings. I think the text meant to read:

Relative IRI (and URL) references SHOULD NOT be used within an Activity Streams 2.0 document due to the fact that many JSON-LD parser implementations are not capable of reliably preserving the base context necessary to properly resolve relative references.

Which would make a lot more sense, since JSON-LD has specific handling of URLs and ID values. (emphasis just to show the change, not to actually emphasize it in the spec)

[trwnh]

JSON-LD processors don't have a problem with this because @base is as widely understood as HTML <base> or base=. I think this is just questionable advice in general. The assumption seems to be that JSON parsers would/can ignore @context entirely, and thus miss out on the @base, @language, etc declarations.

[nightpool]

Yes, as @trwnh says I think you've just misunderstood this section. The whole point of this section is that JSON-LD parsers will recognize @base and be able to interpret the relative URLs correctly, but it was seen as an unreasonable implementation burden to expect pure-JSON consumers to process and dereference relative URIs. especially given that @base statements can be nested or remote and you might get a document like:

{
  "@context": "https://foo.example/context"
  "type": "Like"
  "object": {
    "@context": "https://bar.example/context"
    "id": "my-id",
  },
  "actor": {
    "context": {
      "@base": "https://foobar.example/",
    },
    "id": "my-actor"
  }
}

Which would require two different remote requests to determine the actual id of the liked object, and have three different @base URIs for a given document depending on where in the document the URI lives. Given how technically complicated this would make activity processing, I think it was a wise decision to forbid the use of @base, especially since it only has very negligible benefits (and in fact decreases clarity)

Regardless, whether or not you agree with this conclusion, it was the conclusion of the editors at the time of the spec based on the current consensus of pure-JSON implementors and it is not an errata.

[nightpool]

I think this is just questionable advice in general. The assumption seems to be that JSON parsers would/can ignore @context entirely, and thus miss out on the @base, @language, etc declarations.

I think this is reasonable advice in the world where @context can be remote. I think a good rule of thumb is that pure JSON consumers should not have to manage remote requests or the security issues that may come with them.

[ThisIsMissEm]

In which case it should probably be reworded to be clearer:

Whilst JSON-LD does have capabilities to support relative URLs / ids in documents, plain old JSON parsers are not aware of this, and therefore relative URLs SHOULD NOT be used

[ThisIsMissEm]

It's not that JSON parsers are incapable of doing things with URLs, it's that to a JSON parser a URL carries no specific meaning, it's just a string. So 'my-actor' looks like an invalid URL if you just take it by itself, without going "oh, there's a @base in @context" and making it relative.

It's probably just better to say more advanced JSON-LD syntax like @base should be avoided in activities for maximum compatibility

[evanp]

This is an interesting conversation. I think it makes sense to continue it. I agree that relative URLs don't really work in a world where Activity Streams documents are flowing back and forth among systems, but it may require more discussion to elaborate on why.

[evanp]

Is the fix here to change the ambiguous phrase "base context" to be more specific, like "@base statement in the @context section"?

[evanp]

I think the best next step is to simply remove the word "JSON" to make it clear that many implementations cannot or do not handle relative URLs.

Relative IRI (and URL) references SHOULD NOT be used within an Activity Streams 2.0 document due to the fact that many consumers are not capable of reliably preserving the base context necessary to properly resolve relative references.

It's straightforward and doesn't get too far into the whys and wherefores. Ultimately, the most important things is just using full IRI and URL references.

[evanp]

I've made a PR to update the errata for this issue.

https://github.com/w3c/activitystreams/pull/651