W3C home > Mailing lists > Public > public-linked-json@w3.org > January 2012

Re: compact-0009

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Fri, 6 Jan 2012 14:13:40 -0500
To: Dave Longley <dlongley@digitalbazaar.com>
CC: "public-linked-json@w3.org JSON" <public-linked-json@w3.org>
Message-ID: <AF3C8589-6698-4528-959F-76449298771B@greggkellogg.net>
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.


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.

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.


> -Dave
> -- 
> Dave Longley
> Digital Bazaar, Inc.
Received on Friday, 6 January 2012 19:17:17 UTC

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