Possible use of non-URL values as the base URL in expand()

[kasei]

(Related to #265, #356)

expand() step 5:

If an expandContext option has been passed, update the active context using the Context Processing algorithm , passing the expandContext as local context and expandContext as base URL . If expandContext is a map having an @context entry , pass that entry's value instead.

What if expandContext is not a URL and not a map having a @context entry? This will result in a non-URL being passed as the base URL.

[gkellogg]

And that would result in an error, which is fine.

[kasei]

This is not a well-defined error, though. Context Processing 5.2 just says:

Initialize context to the result of resolving context against base URL.

When this blows up, what is the expected behavior? Ignoring the error? Returning early? Raising an exception?

[gkellogg]

So, you do that resolution and get something. You then attempt to retrieve that something and will get an error. Basically, it's an array, or a map, null, or a string. If it's a string, then it is presumed that resolving against base IRI will result in a string, that may or may not be a valid IRI. If it's not valid, or nothing can be retrieved, it will blow up in 5.2.4 when we attempt to retrieve it.

[kasei]

My contention is that you can't even get to the point of performing "that resolution," because you won't have a base IRI to resolve against. If the base URL is an empty map, I suspect it's going to vary widely how different languages, libraries, and implementations handle trying to turn that into an internal representation of an IRI. I think it's a mistake to rely on that to cause an error in a way that is predictable and can be caught and cleanly handled by the Context Processing algorithm.

[gkellogg]

What language. Would satisfy you? I don’t really see how the base IRai would ever be something like an empty map. It’s either an IRI, or null. Certainly trying to resolve a relative IRI against null doesn’t make sense. We could say to resolve if against base IRI is it is not null, otherwise to just use context as is.

[kasei]

I don’t really see how the base IRai would ever be something like an empty map.

As I mentioned above, expand() step 5 says:

If expandContext is a map having an @context entry, pass that entry's value instead.

That seems to me like any value could be passed as a base URL if it appears as the value in a @context entry of an expandContext map.

It’s either an IRI, or null

Where does this constraint come from?

We could say to resolve if against base IRI is it is not null, otherwise to just use context as is.

I think language that accepts the possibility of base URI not being a valid absolute IRI would be a step in the right direction. Even better would be performing that sort of check before calls to the Context Processing algorithm (in this case, in expand()). In any case, I think there needs to be language that handles this sort of bad data, and is explicit about raising an error condition, and how to handle that error condition.

[gkellogg]

Updated in #377.

[kasei]

@gkellogg the new text for raising a loading document failed error looks good. Thanks.