Make expandContext option in tests a URI instead of a string

[rubensworks]

At the moment, this option is just a string containing a relative URI.
It would be more convenient for test suite handlers to make this option a URI, so that it is resolved to an absolute URI after parsing to RDF.

This will make it consistent with the context property for tests.

[gkellogg]

It’s an API option, and WebIDL doesn’t have a way to do this, that I know of. We could presumably describe a URI prefix for options and parameters but they wouldn’t affect the API definition.

[gkellogg]

Because the options block is used, principally, for describing WebIDL options, and that is a simple key/value dictionary, I don't think we can do this, unless the test README described how to turn such IRIs back into a simple relative string, which is what the API requires.

@dlongley?

[rubensworks]

Because the options block is used, principally, for describing WebIDL options, and that is a simple key/value dictionary, I don't think we can do this, unless the test README described how to turn such IRIs back into a simple relative string, which is what the API requires.

Unless I'm missing something, 9.1 (expand step 5) does not really describe what should happen whenexpandContext is a string/URI, only when it is a map.

One option could be to specifiy that when expandContext is a string, it must be an IRI referring to a context, similar to how it is defined for context in compact().

A URI prefix for options and parameters may also be a good solution, perhaps base could be reused for this.

[gkellogg]

If expandContext is not a map, it is passed to the Context Processing Algorithm, which handles the different forms it might take, including string, but, we could make value expectations more explicit, but this is consistent with compact and flatten, where context might be a map, and is just passed into the algorithm.

[dlongley]

I'm with @gkellogg on this one.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Reject #141, as underlying webIDL spec does not use IRIs, and not our place to recast into them

View the transcript

Gregg Kellogg: Ruben suggest it would be more convenient if we could describe options as IRIs rather than strings.
… In the manifest, options are described by key-value pairs, where values are pairs described in the WebIDL description.
… WebIDL does not support IRIs, it is not our job to do it.
… So I think we should reject this PR.
Dave Longley: I agree
Proposed resolution: Reject #141, as underlying webIDL spec does not use IRIs, and not our place to recast into them (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Dave Longley: +1
Pierre-Antoine Champin: +1
David I. Lehn: +1
Adam Soroka: +1
Benjamin Young: +1
Ivan Herman: +1
Resolution #2: Reject #141, as underlying webIDL spec does not use IRIs, and not our place to recast into them