Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27)

I feel like I am in some weird debate from the 80s.  Seriously.  I swear we
had this same discussion in the ANSI C (X3J11) work in 1986.  Anyway, some
comments inline:

On Tue, Feb 2, 2016 at 3:52 PM, ianbjacobs <notifications@github.com> wrote:

> Implementers of the Browser API (browsers) must not have to do any JSON-LD
> processing.
>
> Ok.
>
> It must be possible to interpret messages passed into the Browser API as
> JSON-LD.
>
> I don't agree with that requirement because that would place an obligation
> on entities
> who are not party to the API. Instead, I think that the API must not
> prevent the use of
> JSON-LD. (It's not clear to me that the spec needs to be explicit about
> that point, but
> by design it should not prevent the use of JSON-LD.)
>

Umm...  I am not sure what sort of an onus/burden you think this is, but in
its basest form JSON-LD is JSON.  Especially with, as @msporny suggested, a
default context.  Surely JS objects are not too much work for developers?
And JSON is well understood. It is a descriptive, extensible, inclusive
grammar that maps most other languages and their datatypes with little
effort.


> Implementations must ignore (and pass through) unrecognized message data.
>
> I don't agree with that yet because I don't think we've had enough
> discussion about error handling.
>

Error handling where?  If the API has defined parameters, then those are
the parameters that are processed.  They have limits?  Specify them.
Behaviors at the edges? Outside of the edges?  Within the domain?  Specify
that too. End of story.  Additional data is cargo.  The error handing is
only on defined parameters.  Otherwise we say "Any data other than the
parameters defined here is passed through" or whatever.  If you want to
allow vendor extensions that are NOT passed through, define a proprietary
extension point for that... e.g. "x_*".  I won't object.



> I do think we should consider an attribute such as "custom" and require
> the processor to
> leave custom data untouched.
>

Hmm.  I would object to that pretty strongly.  We don't need to be
proscriptive to be interoperable.  Just be descriptive about the things we
care about, and permit the rest. Then it will grow / expand in subsequent
phases or organically in the wild or both.  Everyone wins.

—
> Reply to this email directly or view it on GitHub
> <https://github.com/w3c/webpayments/issues/27#issuecomment-178845988>.
>



-- 
-Shane