- From: Shane McCarron <notifications@github.com>
- Date: Sun, 06 Dec 2015 15:01:04 -0800
- To: w3c/webpayments <webpayments@noreply.github.com>
- Message-ID: <w3c/webpayments/issues/30/162361176@github.com>
I actually prefer the mechanism that is required in RDFa Core. It basically states that the URI MUST resolve to something machine readable in an approved format, and then enumerates the approved format(s). And yes, I think JSON-LD is the right way to go for describing payment methods. I would not mind if the URI did content negotiation and could also be viewed as HTML5+RDFa for humans too! [1] http://www.w3.org/TR/rdfa-core/#s_initialcontexts On Sun, Dec 6, 2015 at 4:22 PM, Manu Sporny <notifications@github.com> wrote: > If the payment method identifier is a URL, should there be a resource that > can be fetched from the URL? > > Yes. The resource should be machine-readable (expressed as JSON-LD) for > the reasons specified here: > > http://www.w3.org/TR/json-ld/#introduction > > Is there a need to describe the payment method at the URL or provide some > other information? > > We should not require it, but encourage it. > > At a bare minimum, you could publish a human readable string in various > languages for the payment method. You could also publish the payment > method's branding image. > > You could also make it so that a payment method URL may list the payment > apps that are capable of processing the payment method. This would make it > easy for user agents to retrieve a payment app if one isn't available in > the user agent already. It could address the "no available payment apps" > use case. I'm not suggesting that's how it would work, just that it seems > like there are enough use cases to think more deeply about it. > > — > Reply to this email directly or view it on GitHub > <https://github.com/w3c/webpayments/issues/30#issuecomment-162354066>. > -- Shane McCarron halindrome@gmail.com --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments/issues/30#issuecomment-162361176
Received on Sunday, 6 December 2015 23:01:31 UTC