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: Mon, 26 Aug 2013 17:45:52 +0200
To: <public-linked-json@w3.org>
Message-ID: <019d01cea273$592a3480$0b7e9d80$@lanthaler@gmx.net>
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

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