- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 26 Aug 2013 17:45:52 +0200
- To: <public-linked-json@w3.org>
On Monday, August 26, 2013 5:20 PM, Gregg Kellogg wrote: > On Aug 26, 2013, at 7:56 AM, Dave Longley wrote: > > 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. > > I think that's what we'd need to do; moreover, to survive a > transformation to RDF, I think an inline context would need to be > encoded in a string. Taken as is, a test entry lists input, context, > and expect all as IRIs, which become fully expanded, so the context is > always specified given a URL. If we make it a value (perhaps with a > special datatype), we could then specify an immediate value to be used > for the context. No, lets please not go down that route. If we really need this, I think we should add a flag, something like "passContextAsValue". That being said, I think that's clearly an API test and not an algorithmic test. As such, I think it would be better to include it directly into idltest [1]. We must not forget to add those tests to the implementation reports as well. [1] https://github.com/json-ld/json-ld.org/tree/master/test-suite/idltest -- Markus Lanthaler @markuslanthaler
Received on Monday, 26 August 2013 15:46:21 UTC