Re: compact-0009

On 01/06/2012 02:13 PM, Gregg Kellogg wrote:
> CCing public-linked-json part way through the conversation. The immediate question is about compaction output representation of a specified context, but there is more at the end about general test strategies, and if we are testing the API directly, or a web-services representation.
>
> Gregg
>
> On Jan 6, 2012, at 9:16 AM, Dave Longley wrote:
>
>> On 01/05/2012 08:33 PM, Gregg Kellogg wrote:
>>> [snip]
>>> One more thing, Given that we're specifying the context as a file, it might make more sense to do referenced contexts, as follows:
>>>
>>> {
>>>    "@context": "compact-0009-context.jsonld", // using relative addressing.
>>>    "@id": [
>>>      {
>>>        "homepage": "http://john.doe.org/",
>>>        "name": "John Doe"
>>>      },
>>>      {
>>>      }
>>>    ]
>>> }
>> I assume you just mean as the input to the test (vs. the output). I'm
>> not sure if we want to require the context resolution feature as a
>> prerequisite for testing the other features. But, I guess we could do it
>> that way... thought it means I actually have to write a context resolver
>> for our C++ implementation :P.
> Perhaps we can have some test modes where the context is specified by value, but the question is what should the output look like when invoked via that API? Given that the API tests using objects for both input and context, it makes sense that the content of the context object is effectively merged to the output. The test is structured somewhat differently, as files are given for input, context and output. We should probably make clear in the test-suite documentation that it is testing the API, and that input, context, and frame inputs are to be turned into JSON objects prior to invoking the API.

Yes, that should be documented. Currently, to use the test suite, you 
need to write a small testing harness to do that conversion before 
passing test data to your processor.

> Of course, it's not clear that the test-suite tests the API directly, which would also need to look for exceptions and handle triples provided via callback. This certainly presents some issues for a remote testing infrastructure, which would want to invoke the APIs directly. Easy enough for a JavaScript implementation, but other implementations will need some form of web-services bridge that would retrieve the data over HTTP and mock the API in JavaScript. At any rate, we do need to ensure we've described the requirements for an HTTP interface to the expand/compact/frame/normalize/RDF features.

I'm not sure what the final plan is for how this test-suite will work 
over HTTP; the tests from jsonld.js were just there to get things 
rolling. We could set this up so that you can easily fetch all the tests 
from json-ld.org using whatever custom test-suite software you write for 
your own processor -- or we can require implementors to write their own 
HTTP interface that the test-suite can hit in order to produce a result.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Saturday, 7 January 2012 00:09:14 UTC