Re: Checkout API spec published

> On Feb 8, 2016, at 11:36 PM, Dave Longley <dlongley@digitalbazaar.com> wrote:
> 
> On 02/08/2016 11:55 PM, Ian Jacobs wrote:
>> 
>> 
>> An approach that does not force a single @context value would allow
>> experimentation while still providing a known set of semantics.
> 
> I don't fully understand this comment. To my mind, the @context is what
> provides that known set of semantics. Could you provide some different
> examples?

The current extensibility text [1] concerns me in several ways:

 * It defines processing of JSON-as-JSON-LD which is not, in my view, the
   purview of this group. That is the purview of the JSON-LD specification [2].
   In doing so, it breaks JSON-LD interop because there is a risk that JSON-LD
   processors will interpret the JSON differently (e.g., if @context is sent via an HTTP header,
   and that @context conflicts with this spec, who wins?)

 * It controls the @contact attribute in order to achieve this, meaning that others cannot
   send JSON-LD with other semantics through the pipe. This to me is a show-stopper because it
   prevents extensibility.

 * I believe the text itself has an inconsistency (or at least we want to double check that it doesn’t). On the
   one hand it says "Implementations MUST preserve unrecognized properties and their associated values.”
   On the other it says "If its value does not match, perform JSON-LD compaction on the object using that context.”
   In other words, it says “If you don’t recognize the value, then treat it a certain way rather than preserving it.”

Another approach would be:

 * Clearly state that JSON-LD can be used.
 * Define a @context value that, when provided explicitly, gives rise to the semantics defined in the document.

That approach would:

 * Be simpler.

 * Enable the JSON-LD that is used is interoperable and can be reused out of this API with the same meaning everywhere, rather than
   rely on processors to know this spec.

 * Support extensibility by people who want to use their own JSON-LD vocabularies.

 * Allow processors to evolve over time and still conform to this specification. Otherwise, a “v1” processor would never be able
   to upgrade to handle v1 AND v2 since it would always convert the v2 to v1 semantics.

Ian


[1] https://wicg.github.io/web-payments-browser-api/
[2] https://www.w3.org/TR/json-ld/#the-context

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447