PROPOSAL regarding JSON-LD material

Nick, Adrian,

This is a request to put the following proposal to the group at the 11 February call. This proposal is the result of various discussions since December on this topic (e.g., [1]), as well as discussion at last week's meeting [2]. Our charter [3] requires that any decision be provisional for five business days. My hope is that we will have resolved this in advance of the FTF meeting. I believe that will allow us to focus on important outstanding issues in the "base API” specification(s) at the FTF meeting.

Thank you,

Ian

[1] https://github.com/w3c/webpayments/issues/27
[2] https://www.w3.org/2016/02/04-wpwg-minutes.html
[3] https://www.w3.org/2015/06/payments-wg-charter.html#decisions

========
PROPOSAL

 * In the base API specification(s), JSON (1) is the message format required for conformance.

   I believe this requirement is uncontroversial. Still for discussion within the WG:

    - What is the behavior of conforming processors when they encounter unrecognized properties? I am hearing most support for "leave them and their values untouched."

    - What is the behavior of conforming processors when they encounter unrecognized values of recognized properties? Is the answer "throw an error" and we define that error handling? or ignore them?

 * The Working Group SHOULD publish a companion specification that explains how to use JSON-LD with the API.

 * If the Working Group publishes a companion specification, the base API specification(s) SHOULD include a short, informative reference to that specification. (e.g., with a sentence like "For information about using JSON-LD with this API, see [OtherSpec].”).

=================
ON THIS APPROACH

 * It gives visibility to the use of JSON-LD with the API. I do not yet have a sense of "how normative" that companion specification should be, and therefore this proposal does not address the content and normative status of that specification. By decoupling the JSON-LD  specification, it can evolve independently as the group sees most fit.

 * It keeps the base API specification(s) focused on requirements for implementers of the defined API. It will also shorten that specification.

 * I would like to see work on the companion specification begin soon so that we can start to engage with stakeholders in the ecosystem. That will be important in establishing whether the proposed approach would meet their interoperability needs and thus how normatively we express the material.

=====
NOTES

(1) think it's JSON as defined in ECMA-262 6th edition, and perhaps subsequent editions; I am not focused on the exact source of the definition of standard JSON here.
--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447