- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 8 Feb 2016 21:33:05 -0600
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: public-payments-wg@w3.org
> On Feb 8, 2016, at 9:05 PM, Manu Sporny <msporny@digitalbazaar.com> wrote: > >> On 02/08/2016 04:33 PM, Ian Jacobs wrote: >> It is not appropriate to have a normative reference to material that >> is not required for conformance. > > It's perfectly appropriate to have normative references to material that > tells people how to interpret/extend messages using JSON-LD if they want > to use JSON-LD. If you're not going to interpret the messages as > JSON-LD, you can ignore the normative text. You include text like this > in the API specs so people know that they have the option to interpret > the data as JSON-LD. The external spec itself could have normative language. That does not mean that the base spec needs to have a normative reference to it, especially if there is no dependency. >> I do not believe we understand the ecosystem well enough to require >> JSON-LD. > > Why do you think we're "requiring JSON-LD"? If you don't have a > normative extensibility mechanism, then what's the extensibility > mechanism you're proposing? I am saying I think we need more time to understand the ecosystem. I don't have a proposal other than to get more information before making requirements. >> I support the idea of a standalone specification as a way to build >> the conversation around the use of JSON-LD. > > Is that specification REC-track? Personally I prefer a Note until we have a better sense, but I can live with rec track. > Does it contain normative language on > how to interpret the messages as JSON-LD? I do not think we will achieve Interop unless we have a better sense of the ecosystem and its stakeholders. Until then, I am more comfortable saying "here is one way to do things" rather than "here is the only way." It may be that your proposal accomplishes that; I need to study it more. Ian
Received on Tuesday, 9 February 2016 03:33:19 UTC