Re: remote-doc-manifest

On 09/05/2013 06:07 AM, Markus Lanthaler wrote:
> On Wednesday, September 04, 2013 6:59 AM, Dave Longley
>> On 09/04/2013 12:46 AM, Gregg Kellogg wrote:
>>> On Sep 3, 2013, at 7:13 PM, Dave Longley  wrote:
>>>> I'm currently working on it with jsonld.js. Unfortunately, I'll only
>>>> be able to do this easily in node.js. The phantomJS (headless browser)
>>>> can't fetch documents very easily; it would be nice if we could specify
>>>> something in the manifest that would allow the test application to
>>>> "mock" fetch documents.
> What's the problem? Does neither of the various flags like
>
>    --local-to-remote-url-access=true
>    --web-security=false
>
> solve the problems you are having?

No, unfortunately these are only useful if I'm executing the script 
within a webpage rather than as the primary script. I have to choose 
between having access to the local file system (and other modules) or 
executing the script in a webpage. AFAICT, you can't get access to 
certain APIs from within a page. Everything is easier, faster, and 
simpler with access to the local file system, so I'm not executing the 
script in a page.

> Actually I'm wondering why you submit two
> implementation reports for the same code? The only difference is the runtime
> AFAICT.

The code is not the same. Examples include the code to parse URLs and to 
perform cryptographic hashing (for normalization). Furthermore, I only 
run the promises API in the browser environment; I use the continuation 
callback style API in node.js.

>
>
>>> Yes, I was thinking that too, however, you end up duplicating a lot
>>> of apache config, and you'd need to be sure that a test runner
>>> accurately represented it. However, we could figure out a way to
>>> express the parameters in the manifest with some additional option
>>> properties.
>> Yeah, I think it's worth expressing it in the manifest to make it easier
>> on anyone with a test environment that can't necessarily hit the
>> json-ld.org server (or fetch any docs for that matter).
> I think the whole purpose of these tests is to test that an implementation
> is capable of making real network requests.

I think it's perfectly fine for there to be an abstraction layer between 
the network and what remote documents are returned. I don't think we're 
trying to test the network stack here, rather we're trying to ensure 
that remote documents that are loaded with particular parameters produce 
appropriate output. Think of it as if a different "HTTP adapter" is used 
for testing. The test is not for the adapter, it's for what it returns.


>   As such, I think mocking them
> wouldn't be a good idea. In practice, you probably run the code in an
> environment where it doesn't have network access, but nevertheless it MUST
> be able to perform those requests.

I don't think that we should say that a processor with no access to 
json-ld.org is incapable of being considered compliant. It certainly 
wouldn't be able to prove its compliance if such access were required. 
The processor might do everything just fine w/respect to loading remote 
documents, but be unable to access *particular* remote documents.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Thursday, 5 September 2013 14:47:59 UTC