<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I am fine with /Contract/Party/obligations/to syntax. <br>
<br>
=nat<br>
<br>
(2010/05/11 15:50), David Garc&iacute;a wrote:
<blockquote
 cite="mid:AANLkTikTf3iWvdPRy4lWFMM2UuFAs6AB1LWHqF8ni4gv@mail.gmail.com"
 type="cite">Hi Nara,<br>
  <br>
doing multilateral obligations with /Contract/Party/obligation/to fits
for me. It's kinda REST syntax.<br>
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.<br>
  <br>
Best regards<br>
  <br>
Dave<br>
  <br>
  <div class="gmail_quote">2010/5/11 nara hideki <span dir="ltr">&lt;<a
 moz-do-not-send="true" href="mailto:hdknr@ic-tact.co.jp">hdknr@ic-tact.co.jp</a>&gt;</span><br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">H,
Nat and David.<br>
    <br>
I think that /Contract/Party/obligation seems to be better.<br>
    <br>
&nbsp;1. &nbsp;easier to grasp stakeholders in a contract<br>
&nbsp;2. &nbsp;each party must sign the contract document and a signature<br>
element must be needed.<br>
&nbsp;3. &nbsp;an obligation could be 1 to N relations. Multiple<br>
/Contract/Party/obligation/to can be used.<br>
&nbsp;4. &nbsp;a party can owe multiple obligation to different parties in a
contract.<br>
    <br>
One thing we should think of &nbsp;is &nbsp;an obligation to "any party in
contract".<br>
Although we can provide every obligation to each party, but a wildcard<br>
is quite useful especially when<br>
the number of parties are big.<br>
    <br>
&nbsp;----<br>
hdknr<br>
    <br>
2010/5/7 David Garcia &lt;<a moz-do-not-send="true"
 href="mailto:david.garcia@tractis.com">david.garcia@tractis.com</a>&gt;:<br>
    <div>
    <div class="h5">&gt; +1 to the second one. I think it's more
powerful on multilateral contracts,<br>
&gt; because it allows to define party to party obligations with a fine
grain<br>
&gt; detail.<br>
&gt; Best regards<br>
&gt;<br>
&gt; David Garcia<br>
&gt; El 07/05/2010, a las 06:36, Nat Sakimura &lt;<a
 moz-do-not-send="true" href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>&gt;
escribi&oacute;:<br>
&gt;<br>
&gt; In the current draft, &lt;obiligation&gt; is an child element of
&lt;party&gt;. However,<br>
&gt; when we think about the multi-party scenario,<br>
&gt; unless we specify the target that the party is obliged to, it
would have no<br>
&gt; meaning.<br>
&gt; Thus, we would have two ways to implement it.<br>
&gt; 1. destination as an attribute.<br>
&gt; &lt;obligation to="partyid"&gt;<br>
&gt; 2. Flatten obligations.<br>
&gt; &lt;obligation from="partyaid" to="partybid"&gt;<br>
&gt; Which do you think is better?<br>
&gt; From the point of view of writing an application, the second
option may be<br>
&gt; easier.<br>
&gt; --<br>
&gt; Nat Sakimura (=nat)<br>
&gt; <a moz-do-not-send="true" href="http://www.sakimura.org/en/"
 target="_blank">http://www.sakimura.org/en/</a><br>
&gt; <a moz-do-not-send="true" href="http://twitter.com/_nat_en"
 target="_blank">http://twitter.com/_nat_en</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Specs-cx mailing list<br>
&gt; <a moz-do-not-send="true" href="mailto:Specs-cx@lists.openid.net">Specs-cx@lists.openid.net</a><br>
&gt; <a moz-do-not-send="true"
 href="http://lists.openid.net/mailman/listinfo/openid-specs-cx"
 target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-cx</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Specs-cx mailing list<br>
&gt; <a moz-do-not-send="true" href="mailto:Specs-cx@lists.openid.net">Specs-cx@lists.openid.net</a><br>
&gt; <a moz-do-not-send="true"
 href="http://lists.openid.net/mailman/listinfo/openid-specs-cx"
 target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-cx</a><br>
&gt;<br>
&gt;<br>
    </div>
    </div>
  </blockquote>
  </div>
  <br>
  <br clear="all">
  <br>
-- <br>
David Garcia<br>
CTO<br>
Tractis - Online contracts you can enforce<br>
  <a moz-do-not-send="true" href="http://www.tractis.com">http://www.tractis.com</a><br>
--<br>
Email: <a moz-do-not-send="true" href="mailto:david.garcia@tractis.com">david.garcia@tractis.com</a><br>
Skype: deiffbcn<br>
Blog: <a moz-do-not-send="true" href="http://blog.negonation.com">http://blog.negonation.com</a><br>
Linkedin: <a moz-do-not-send="true"
 href="http://www.linkedin.com/in/davebcn">http://www.linkedin.com/in/davebcn</a><br>
  <br>
  <br>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Specs-cx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Specs-cx@lists.openid.net">Specs-cx@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-cx">http://lists.openid.net/mailman/listinfo/openid-specs-cx</a>
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Nat Sakimura (<a class="moz-txt-link-abbreviated" href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd. 
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

&#26412;&#12513;&#12540;&#12523;&#12395;&#21547;&#12414;&#12428;&#12427;&#24773;&#22577;&#12399;&#27231;&#23494;&#24773;&#22577;&#12391;&#12354;&#12426;&#12289;&#23451;&#20808;&#12395;&#35352;&#36617;&#12373;&#12428;&#12390;&#12356;&#12427;&#26041;&#12398;&#12415;&#12395;&#36865;&#20449;&#12377;&#12427;&#12371;&#12392;&#12434;&#24847;&#22259;&#12375;&#12390;&#12362;&#12426;&#12414;&#12377;&#12290;&#24847;&#22259;&#12373;&#12428;&#12383;&#21463;&#21462;&#20154;&#20197;&#22806;&#12398;&#26041;&#12395;&#12424;&#12427;&#12371;&#12428;&#12425;&#12398;&#24773;&#22577;&#12398;&#38283;&#31034;&#12289;&#35079;&#35069;&#12289;&#20877;&#37197;&#24067;&#12420;&#36578;&#36865;&#12394;&#12393;&#19968;&#20999;&#12398;&#21033;&#29992;&#12364;&#31105;&#27490;&#12373;&#12428;&#12390;&#12356;&#12414;&#12377;&#12290;&#35492;&#12387;&#12390;&#26412;&#12513;&#12540;&#12523;&#12434;&#21463;&#20449;&#12373;&#12428;&#12383;&#22580;&#21512;&#12399;&#12289;&#30003;&#12375;&#35379;&#12372;&#12374;&#123
56;&#12414;&#12379;&#12435;&#12364;&#12289;&#36865;&#20449;&#32773;&#12414;&#12391;&#12362;&#30693;&#12425;&#12379;&#12356;&#12383;&#12384;&#12365;&#12289;&#21463;&#20449;&#12373;&#12428;&#12383;&#12513;&#12540;&#12523;&#12434;&#21066;&#38500;&#12375;&#12390;&#12356;&#12383;&#12384;&#12365;&#12414;&#12377;&#12424;&#12358;&#12362;&#39000;&#12356;&#33268;&#12375;&#12414;&#12377;&#12290;
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. 
</pre>
</body>
</html>