Re: Checkout API spec published

On 02/08/2016 11:05 AM, Adrian Hope-Bailie wrote:
> When combined with the revised browser API proposal from the CG it 
> seems to tick many of the boxes we want to cover.

That was what we were attempting to do, so it's nice to see some
validation on the attempt, thanks AdrianHB. :)

> Would it not make sense for the Extensibility section of the browser 
> API to stand alone in it's own document that describes the full 
> end-to-end flow of data from semantic markup of an offer in a search 
> result to payment to receipt email with semantic markup?

It would if:

1. The reference to the Messages spec from the browser-based API specs
   was normative.
2. There was a Messages / Extensibility specification that was
   REC-track.

If those two things happen, then we could take the section out and put
it elsewhere, but only if we're clear about how all of this is
interpreted as JSON-LD.

To put it another way, it's a part of the narrative, it's clear what we
mean, and there is normative language around JSON-LD.

What we don't want is to point to some informative note on how to extend
the messages using JSON-LD because that won't lead to interoperability.

> I can imagine at least 5 documents that we could produce on the back 
> of this work:

#1-#4 seem just fine to me. I don't have an opinion on #5 (card payments
spec) because I don't really know how that spec would work.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
https://manu.sporny.org/2015/payments-collaboration/

Received on Monday, 8 February 2016 21:22:00 UTC