- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 20 Mar 2012 15:45:04 -0400
- To: Web Payments <public-webpayments@w3.org>
Thanks to Dave Longley for scribing! The minutes for today's telecon are available here: http://payswarm.com/minutes/2012-03-20/ Full text of the discussion follows for archival purposes at the W3C. --------------------------------------------------------------------- Web Payments Community Group Telecon Minutes for 2012-03-20 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2012Mar/0035.html Topics: 1. PaySwarm Reference Implementation 2. Vocabulary Review - Commerce 3. Commerce Vocabulary Classes 4. Commerce Vocabulary Constants 5. Commerce Vocabulary Properties Facilitator: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn, David Nicol, Jeff Sayre Audio: http://payswarm.com/minutes/2012-03-20/audio.ogg Dave Longley is scribing. Manu Sporny: The above link is for the day's agenda. Manu Sporny: We'll be going over some vocabularies related to payswarm. Topic: PaySwarm Reference Implementation Manu Sporny: https://dev.payswarm.com/ Manu Sporny: Skipping this because there aren't any people that haven't seen it on the call. Manu Sporny: We're going to first discuss the commerce vocabulary. Topic: Vocabulary Review - Commerce Manu Sporny: The main thing to try and understand with this vocabulary is to see what we might be able to get rid of (cut down) or things we might want to consolidate into the vocab. David I. Lehn: http://payswarm.com/specs/source/vocabs/commerce David I. Lehn: that's the latest one. we should look at that Manu Sporny: so we'll go from the top-level classes down into the constants and properties. Topic: Commerce Vocabulary Classes Manu Sporny: Deposit, Account, Payee, all straightforward and needed. Dave Longley: PayeeRule is necessary, we use it - tells us what people allow to be tacked on to the prices they list... [scribe assist by Manu Sporny] Manu Sporny: Wo we're keeping all of the classes in the commerce vocab. Manu Sporny: Are there any classes we need to be adding to the vocab? Manu Sporny: Last week we discussed the security vocab and it needed some work, but commerce seems fairly solid. Manu Sporny: Would credit card, banking account go in here? Manu Sporny: One specifically for each. Dave Longley: We might also wrap all of the payment methods into a Payment vocab. Dave Longley: We were also talking about a 'pay' vocabulary and wrapping those things up into a single vocabulary - credit cards, banking information, etc. [scribe assist by Manu Sporny] Manu Sporny: So we can talk about the pay vocab and the credit card vocab at the same time later. Topic: Commerce Vocabulary Constants Manu Sporny: On to the constants listed in the vocab... Manu Sporny: http://payswarm.com/specs/source/vocabs/commerce#toc David I. Lehn: Our code has Exclusive/Inclusive w/o the "Percentage" extension Dave Longley: We use all of the constants in the vocabulary now... so we don't need to get rid of any of them. We have made some changes - we don't have exclusivePercentage and inclusivePercentage anymore... I think we just have percentage [scribe assist by Manu Sporny] Dave Longley: We have 'rate' and 'rateContext' now... 'rateContext' specifies how you understand the rate [scribe assist by Manu Sporny] Dave Longley: Exclusive percentage is something like a sales tax... [scribe assist by Manu Sporny] Dave Longley: Inclusive percentage is a way of calculating the total w/o modifying the total... so if you want the article to be $0.05 - payee rule w/ inclusive percentage of 2% would mean the article will always be $0.05... [scribe assist by Manu Sporny] Manu Sporny: Exclusive percentage, add on to the total, inclusive percentage doesn't modify the total, it breaks up the percentages within the total for different destinations. Dave Longley: 'rate' can only be percentage or flat amount [scribe assist by Manu Sporny] Dave Longley: 'rateContext 'determines how 'rate' is used to calculate the final amount. [scribe assist by Manu Sporny] Manu Sporny: We don't have how to resolve payees in the specs anywhere, right now, right? [scribe assist by Manu Sporny] Dave Longley: Yeah, we need to add that to the specs. [scribe assist by Manu Sporny] Dave Longley: Commerce spec should be changed to remove ExclusivePercentage and InclusivePercentage. [scribe assist by Manu Sporny] David I. Lehn: Which is more up to date the implementation or the spec w/respect to Exclusive/Inclusive Percentage? Dave Longley: Commerce spec should be modified to add constants for Percentage, Exclusive, and Inclusive. [scribe assist by Manu Sporny] Manu Sporny: We'll want to take a look and see if there's any way we can simplify this. David I. Lehn: dln, tilgovi: We're chatting over voip now, you are welcome to join Manu Sporny: We need to remove ExclusivePercentage, InclusivePercentage and add Percentage, Exclusive, and Inclusive. Topic: Commerce Vocabulary Properties Manu Sporny: Looking at 'account', 'source' and 'destination' - we need all three? [scribe assist by Manu Sporny] David I. Lehn: If you look at the account, it specifies the account for a person, it isn't a source or a destination. Manu Sporny: We can use it to list all of the public accounts on an identity page. Manu Sporny: We marked up the previous demo in RDFa using that. Dave Longley: I don't remember if we had to have 'account'... 'account' was bleeding into cases where we need to use 'source' or 'destination' [scribe assist by Manu Sporny] Dave Longley: We need to be more clear in spec language on when you use 'com:account' vs. 'com:destination' [scribe assist by Manu Sporny] David Nicol: What about 'vendor' and 'customer' [scribe assist by Manu Sporny] David Nicol: There are/we want more layers, many layers of little definitions Manu Sporny: http://payswarm.com/specs/source/vocabs/commerce#account Manu Sporny: that link gives an example that describes a person that has an account David Nicol: Has the Payswarm vocab named the layers? Manu Sporny: We achieve layers by saying there are "identities" with "accounts" (two layers) ... Manu Sporny: We have identity as one layer and account as another. Manu Sporny: There is a distinction between account, source, and destination, we need all three Manu Sporny: 'amount' is next... refers to a number of bitcoins, dollars, etc. Manu Sporny: 'amount' only specifies the value, not the unit of measurement. Manu Sporny: Unit of measure is com:currency which is next David I. Lehn: Possible problem with inconsistency between string and IRI for the value of a currency Manu Sporny: We could come up with a string for each alternative currency Manu Sporny: If we can specify currency mints we get problems Dave Longley: Why don't we just normalize and always use IRIs David I. Lehn: There isn't an official IRI for USD, etc. David Nicol: That's one less thing for ICANN to do, if this working group takes ownership of the comprehensive list of short currency codes Manu Sporny: We could do something like this - "com:currency": "iso4217:USD" or this "com:currency": "cur:USD"? David Nicol: iso4217 will drift, that's one issue. Requiring upgrading when it happens. Manu Sporny: Do we need com:date? [scribe assist by Manu Sporny] Dave Longley: We were definitely using dc:created for signature creation... [scribe assist by Manu Sporny] Dave Longley: Transactions may not be created at the same time they're authorized... so "com:date" is not the same thing as "dc:created". [scribe assist by Manu Sporny] Dave Longley: Any time we authorize or finalize a transaction, we use "com:date" [scribe assist by Manu Sporny] David I. Lehn: I have marked some places where we need to go back and look at it Dave Longley: Source or destination seems to be more specific - you can't misunderstand that in the same way as to/from (which can be about identities, or it can be about accounts) [scribe assist by Manu Sporny] Jeff Sayre: +1 David Nicol: to/from is at identity layer and source/destination is at account layer? Manu Sporny: David Nicol, effectively, yes. We should keep source and destination because they are more specific to accounts... Manu Sporny: and they enable more layers of differentiation between identity, financial account, etc. Manu Sporny: next up is 'destinationOwnerType' David Nicol: and not lose to/from as they pertain to something subtly differnt Dave Longley: Yeah, this is important for making the differentiation in PayeeRules, so we need it. [scribe assist by Manu Sporny] Manu Sporny: it is used in a payee rule, to specify that the only particular owners of destination accounts can take a cut of a sale, etc. Manu Sporny: We need to move gatewayApprovalCode and gatewayError in the Payment vocabulary... not in the Commerce vocabulary. [scribe assist by Manu Sporny] Dave Longley: Yeah, this is one of those things that bled into this vocab, we need to move it out. [scribe assist by Manu Sporny] Manu Sporny: we're moving all of the gateway related properties to the payment vocabulary. Manu Sporny: any concerns about doing that change? David I. Lehn: That's fine, i haven't noticed gateway error before Dave Longley: The example for gatewayError is bad, but we may need to return this in exceptions. [scribe assist by Manu Sporny] David I. Lehn: It seems like it would be part of a response in some generic exception system Manu Sporny: 'maximumRate' is used Dave Longley: I think we need to add minimumRate to the spec. [scribe assist by Manu Sporny] Manu Sporny: forTransaction is for reverse linking transfers to the transaction they are a part of David Nicol: ...something about Ted Waitt (ed: founder of Gateway Computers) David I. Lehn: we don't have minimumRate anywhere in our code. maybe that wasn't needed? David I. Lehn: I'm not sure ... will have to go back and look. Dave Longley: We may not need "com:forTransaction"... [scribe assist by Manu Sporny] Dave Longley: I don't know if we minted any URLs for transfers. [scribe assist by Manu Sporny] Dave Longley: If we did give them URLs, then we would want reverse links... but if they're just embedded inside transactions, maybe we don't need it. [scribe assist by Manu Sporny] Dave Longley: If we have a transfer as a starting point in the database, then we may need forTransaction. [scribe assist by Manu Sporny] Manu Sporny: We can't think of a good reason for forTransaction but we should double check before removing it. Manu Sporny: We could go through the payswarm reference demo now and answer some questions about it? Jeff Sayre: I think the time would be best spent going through the vocab. David Nicol: Agreed that time would be best spent talking about the vocab. Dave Longley: Maybe next time we can start out with the demo quickly. Manu Sporny: 'limitation' is next, it allows people who sign listings to specify that they don't want anyone else taking a cut of a sale. Manu Sporny: Can be used to prevent affiliate type sales David Nicol: We don't want to bring issues from business layer down here David Nicol: rules about "no multi-level" -- no reselling? Dave Longley: I think we need com:limitation - need a way to specify that someone shouldn't get paid. [scribe assist by Manu Sporny] David Nicol: Just don't want to put anything complex here Dave Longley: We need a vocabulary that specifies rules for who gets paid... we need to give some basic set of rules somewhere. [scribe assist by Manu Sporny] Manu Sporny: Well, the question is what vocabulary the terms should go in. [scribe assist by Manu Sporny] Dave Longley: I'm for breaking it out into a separate vocabulary - but it's something that we absolutely need. [scribe assist by Manu Sporny] Manu Sporny: Anything associated with business rules, payee limitations, etc. should be shifted to another vocab maybe. David I. Lehn: Soon we will have a vocabulary explosion problem if we keep splitting vocabularies David Nicol: layers are good Manu Sporny: It's good to understand where the layers are Manu Sporny: Commerce should maybe have two layers low-level accounts, and high-level 'what makes the money dance around' ... rules about how the money can move between accounts, in exchange for assets, etc. Dave Longley: Yes, we need to find a good balance here, so we don't have a vocab explosion but we don't want to mix layers and get things muddled. Manu Sporny: We could split the vocab documents into 2, 'high' and 'low' levels. Manu Sporny: moving on Manu Sporny: 'minimumAmount' is already here, what about 'minimumRate'? [scribe assist by Manu Sporny] Dave Longley: The reason we have 'minimumAmount' is to specify a floor to the amount that one would collect... [scribe assist by Manu Sporny] Manu Sporny: minimumAmount specifies a floor Dave Longley: Once payee amounts are resolved, they can't be below that floor. Manu Sporny: 'payeePosition' is next and is important because it can be used in the payee algorithm Manu Sporny: We need to spec out payeePosition a bit more if we keep it Manu Sporny: We might just use @list in JSON-LD now to avoid having to specify the order by property David I. Lehn: We need to be clear about what the order is and how its used Manu Sporny: So we need to decide if we can get rid of it... if so, we should probably drop it. Dave Longley: Having the position helps people know to be specific David Nicol: 'payeePosition' is a complicated business rule that only comes into effect when there is a short payment Manu Sporny: The algorithm and everything is complicated enough we're going to need visual depiction, etc. David I. Lehn: If order is external instead of inside the object you could reuse them. Dave Longley: We don't always give them @ids right now, but if they have @ids they could be reused Dave Longley: If the payees have @ids, then we may want to reuse them in different places, which is an argument against having payeePosition. [scribe assist by Manu Sporny] Manu Sporny: Which is an argument against payeePosition Manu Sporny: Top of the hour, we need to wrap up the call. David I. Lehn: <currency currencyScheme="http://www.fpml.org/ext/iso4217">DEM</currency> David I. Lehn: fpml has some scheme thing. they require registration to look at the spec though. just found an example on their site. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: PaySwarm Website for Developers Launched http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Tuesday, 20 March 2012 19:45:40 UTC