[Specs-cx] Multi-party contract

[Nat Sakimura]

I am fine with /Contract/Party/obligations/to syntax.

=nat

(2010/05/11 15:50), David García wrote:
> Hi Nara,
>
> doing multilateral obligations with /Contract/Party/obligation/to fits 
> for me. It's kinda REST syntax.
> This solution and the one proposed by Nat are both good if we define 
> wildcards on Nat's, because as Nara said the "any" wildcard would be 
> very useful.
>
> Best regards
>
> Dave
>
> 2010/5/11 nara hideki <hdknr at ic-tact.co.jp <mailto:hdknr at ic-tact.co.jp>>
>
>     H, Nat and David.
>
>     I think that /Contract/Party/obligation seems to be better.
>
>      1.  easier to grasp stakeholders in a contract
>      2.  each party must sign the contract document and a signature
>     element must be needed.
>      3.  an obligation could be 1 to N relations. Multiple
>     /Contract/Party/obligation/to can be used.
>      4.  a party can owe multiple obligation to different parties in a
>     contract.
>
>     One thing we should think of  is  an obligation to "any party in
>     contract".
>     Although we can provide every obligation to each party, but a wildcard
>     is quite useful especially when
>     the number of parties are big.
>
>      ----
>     hdknr
>
>     2010/5/7 David Garcia <david.garcia at tractis.com
>     <mailto:david.garcia at tractis.com>>:
>     > +1 to the second one. I think it's more powerful on multilateral
>     contracts,
>     > because it allows to define party to party obligations with a
>     fine grain
>     > detail.
>     > Best regards
>     >
>     > David Garcia
>     > El 07/05/2010, a las 06:36, Nat Sakimura <sakimura at gmail.com
>     <mailto:sakimura at gmail.com>> escribió:
>     >
>     > In the current draft, <obiligation> is an child element of
>     <party>. However,
>     > when we think about the multi-party scenario,
>     > unless we specify the target that the party is obliged to, it
>     would have no
>     > meaning.
>     > Thus, we would have two ways to implement it.
>     > 1. destination as an attribute.
>     > <obligation to="partyid">
>     > 2. Flatten obligations.
>     > <obligation from="partyaid" to="partybid">
>     > Which do you think is better?
>     > From the point of view of writing an application, the second
>     option may be
>     > easier.
>     > --
>     > Nat Sakimura (=nat)
>     > http://www.sakimura.org/en/
>     > http://twitter.com/_nat_en
>     >
>     > _______________________________________________
>     > Specs-cx mailing list
>     > Specs-cx at lists.openid.net <mailto:Specs-cx at lists.openid.net>
>     > http://lists.openid.net/mailman/listinfo/openid-specs-cx
>     >
>     > _______________________________________________
>     > Specs-cx mailing list
>     > Specs-cx at lists.openid.net <mailto:Specs-cx at lists.openid.net>
>     > http://lists.openid.net/mailman/listinfo/openid-specs-cx
>     >
>     >
>
>
>
>
> -- 
> David Garcia
> CTO
> Tractis - Online contracts you can enforce
> http://www.tractis.com
> --
> Email: david.garcia at tractis.com <mailto:david.garcia at tractis.com>
> Skype: deiffbcn
> Blog: http://blog.negonation.com
> Linkedin: http://www.linkedin.com/in/davebcn
>
>
>
> _______________________________________________
> Specs-cx mailing list
> Specs-cx at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-cx
>    


-- 
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-cx/attachments/20100511/5ebf07ad/attachment.htm>