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

RE: Context processing of object without @context

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 27 Aug 2013 12:54:48 +0200
To: "'JSON JSON'" <public-linked-json@w3.org>
Message-ID: <01d001cea313$d9e235f0$8da6a1d0$@lanthaler@gmx.net>
On Monday, August 26, 2013 7:35 PM, Gregg Kellogg wrote:
> > 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.

If that's what people should do, we should document it somewhere. I test
directly against the files in the repo (locally)

> >> 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.

Yeah, I know but the thing is that people will process this as JSON and not
as JSON-LD. After all they are testing their JSON-LD implementation so it's
kind of a chicken-and-egg problem. By directly using the absolute IRIs
people would instinctively use the remote documents instead of passing the
content of the local files directly.

The question still is what we want. I see no particular reason to use remote
documents everywhere, quite the contrary as it makes the tests much much
slower. Of course we should have one or two remote documents as well.. but
that can be tested as part of the API tests (idltest) as well.


--
Markus Lanthaler
@markuslanthaler
Received on Tuesday, 27 August 2013 10:55:21 UTC

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