W3C home > Mailing lists > Public > public-linked-json@w3.org > August 2013

Re: Context processing of object without @context

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Mon, 26 Aug 2013 10:56:16 -0400
Message-ID: <521B6C90.8020003@digitalbazaar.com>
To: public-linked-json@w3.org
On 08/26/2013 02:11 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.
>
>  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).

Hmm, this is problematic because there is different behavior (sometimes, 
eg: @base?) for remote contexts vs. local ones. I don't think that we're 
always supposed to treat the parameter given to the API document as a 
remote context (if it is a URL, yes, but otherwise no). So, we wouldn't 
have any way, other than inlining the contexts in the manifests, to 
specify that a context is not remote. It would be better, perhaps, to 
specify that the test suite context given in by context parameter is 
*not* remote. Rather, if that context references another one via a URL, 
only then will the context be considered remote. This gives us the 
ability to provide both types of contexts for testing.

> 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": {}
> }
>
> 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.
>
> Gregg Kellogg
> gregg@greggkellogg.net
>
> [1] http://json-ld.org/minutes/2013-08-06/#resolution-1
> [2] http://json-ld.org/test-suite/tests/compact-0001-context.jsonld
>
>


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Monday, 26 August 2013 15:06:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:39 UTC