Re: Context processing of object without @context

On Aug 26, 2013, at 8:37 AM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:

> On Monday, August 26, 2013 8:12 AM, Gregg Kellogg wrote:
>> Step 3.2.3 of the Context Processing Algorithm still indicates that
>> it's an error if the dereferenced context is not an object containing
>> @context. Looking in the resolution we did on Aug 6 [1], the CG agreed
>> that remote context documents are required to contain @context to be
>> valid. However, our tests (e.g., compact-0001) are defined through a
>> manifest the references IRIs for the input document and context.
>> compact-0001-context.jsonld [2], is in fact, a document containing an
>> empty object. There are numerous other tests that are much like this.
>> 
>> Clearly, either people have been running these tests by dereferencing
>> the test files and providing them as immediate values to the
>> algorithms, or have some other mechanism which allows for an empty
>> object. (In my case, I was running these tests in a more permissive
>> mode before, and thus did not stop when this was detected.
> 
> My processor doesn't raise all the errors mentioned in the spec yet. In this
> case, it simply ignores the remote context.
> 
> 
>> From the API, if the input document is a DOMString, it's dereferenced
>> before calling the algorithm; this is not the case for a context. We
>> should clarify that the test runner should treat each test parameter as
>> a DOMString (being the absolute IRI that is the property value, after
>> fully expanding the manifest based on it's URL).
> 
> Should people test directly against json-ld.org/w3.org, set up a local
> server, or use the context loader feature? 

I test against json-ld.org and cache the results.

>> The easiest resolution for the test cases would be to change all
>> context documents containing just an empty object to contain an empty
>> context:
>> 
>> {
>>  "@context": {}
>> }
> 
> +1
> 
> 
>> I recall having this discussion some time ago, and some people passed
>> the context as a value, while others as an IRI. I think it's clear that
>> the test manifest provides an IRI, and we need to be clear that we're
>> invoking the algorithms appropriately.
> 
> If that's really what we want, we should perhaps include the absolute IRI
> instead of just the filename.

It's treated as a relative IRI, so if you expand the manifest relative to its location, you automatically get the absolute IRI. Otherwise, all of input, context and expect must be resolved relative to the manifest anyway. The values aren't strings, they're IRIs.

Gregg
> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Monday, 26 August 2013 17:35:42 UTC