RE: Context processing of object without @context

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


Markus Lanthaler

Received on Monday, 26 August 2013 15:46:21 UTC