- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Thu, 5 May 2016 00:30:58 +0200
- To: Ian Jacobs <ij@w3.org>
- Cc: Adrian Bateman <adrianba@microsoft.com>, Zach Koch <zkoch@google.com>, Payments WG <public-payments-wg@w3.org>
- Message-ID: <CA+eFz_JEJKD-KYt3R7xjat8=EcCF1sWHuWOAO7J6DkvxuhnOxg@mail.gmail.com>
> I am hearing Adrian B say “They will never see Recommendation.” Having “not been recommended” they will not need to be deprecated. So what is the motivation for having them at all? On 4 May 2016 at 21:57, Ian Jacobs <ij@w3.org> wrote: > > > On May 4, 2016, at 2:44 PM, Adrian Hope-Bailie <adrian@hopebailie.com> > wrote: > > > > > · The short string list below effectively covers 5 > organisations. Our goal should be to drive this list to zero before > Candidate Recommendation. > > > > This reinforces my belief that short-strings/aliases are adding more > complexity than value. > > I second Manu's caution that once we start using them they will never be > deprecated. > > > > We should also consider Matt Saxon's assertion that the card payments > method spec should not jsut be for basic card payments and should evolve to > include new ways of passing card payment data in future (as opposed to > having a new card payments method spec). > > > > i.e. Will we mark these short strings as deprecated in future versions > of the spec or how do we realistically phase them out? > > I am hearing Adrian B say “They will never see Recommendation.” Having > “not been recommended” they will not need to be deprecated. > We will need to mark them loudly as such. > > Ian > > > > > > On 4 May 2016 at 19:51, Ian Jacobs <ij@w3.org> wrote: > > > > > On May 4, 2016, at 10:39 AM, Adrian Bateman <adrianba@microsoft.com> > wrote: > > > > > > Zach and I discussed this before he sent this mail so I support the > proposal. > > > > > > A couple of additional thoughts: > > > > > > · The short string list below effectively covers 5 > organisations. Our goal should be to drive this list to zero before > Candidate Recommendation. > > > > > > > Thanks, that additional bit of information helps. > > > > I am also ok with the proposal. > > > > This approach simplifies the related topics: > > > > * Equivalence testing (use [1]). > > * Minting policy: Anybody can mint their own absolute URLs. > > * Identified resources: We can decide later, have flexibility, etc. > > > > Ian > > > > [1] https://www.w3.org/TR/payment-method-id/#identifier-equivalence > > > > > > > · One of the motivations is to not get into the “short-string > registry” business. Any time someone wants to add themselves to the list, > they just need to mint a URL and we will use it. > > > > > > · For now, we are only discussing these strings as identifiers. > In the future, though, we will no doubt discuss what resources the URLs > might point to. If we use the relative URL approach that I proposed in > Option 1a then this potentially puts a lot of network load on whoever hosts > the base URL. > > > > > > This was a problem in the past when W3C hosted DTDs and XML namespace > schema (in the past, Microsoft’s network was regularly rate limited to > w3.org because of errant software running on machines behind our proxies > that was frequently downloading schema definitions). > > > > -- > > Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs > > Tel: +1 718 260 9447 > > > > > > > > > > -- > Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs > Tel: +1 718 260 9447 > > > >
Received on Wednesday, 4 May 2016 22:56:43 UTC