OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [legalxml-econtracts] Minutes Draft July 2 - v1


I have unintentionally missed the last two meetings because I have not calendared them. Is there a notice on the website? Can someone perhaps make a note to notify me? I would like to participate but seem just to get minutes after the fact, and I am not sure why this is happening. Thanks.

---------- Original Message ----------------------------------
From: Dave Marvit <dave@marvit.org>
Date:  Wed, 9 Jul 2003 11:21:23 -0700

>Folks,
>
>Here is a set of draft minutes for the July 2 conference call. As 
>always, comments are appreciated.
>
>Best,
>
>Dave Marvit
>Fujitsu labs of America
>dave@marvit.org
>
>--------
>Draft Minutes (Version 1)
>OASIS LegalXML eContracts Technical Committee
>July 2, 2003 Conference Call.
>
>
>Summary:
>
>- Some discussion about scheduling a face to face in SF
>- Rolly presenting his construction contracts scenario
>
>----------------------
>
>The following were present:
>
>Rolly Chambers
>Charles Gillam
>Dan Greenwood
>Jason Harrop
>Dr. Leff
>Dave Marvit
>John McClure
>Zorin Milosevic
>
>Discussion about face-2-face in SF concluded as follows:
>- We have an hour from 9 to 10 in the Fairmont hotel to discuss things 
>(a mini-face-2-face) with the cyber-law group.
>- We will shoot for Saturday, Aug 9th, late morning through late 
>afternoon for a face to face. (noon to 5 or so). Moe information on a 
>venue is pending.
>
>
>Starting the meeting:
>
>DG: I believe that our only agenda item is Rolly's scenario.
>
>Rolly:  I'l keep it short and sweet. I want to thank Jason, Zorin, and 
>Peter for letting me shamelessly plagiarize their good work on the 
>other scenarios.
>
>When I started I was interested in taking the general information item 
>that Jason et al. had described and seeing if those items could and 
>might apply to marking up construction contracts. I was trying to see 
>what we already had and apply it in a specialized contractual settings.
>
>I did that, proceeding as Jason had - considering the document 
>generation and management challenge more than the automation challenge. 
>After going through the exercise I am satisfied that the information 
>items generate for other scenarios apply well to construction contracts.
>
>Notice, event, obligation, outcome,title, date, and governing law all 
>apply readily to construction contracts. In particular we need to 
>explore and experiment more with the obligation item.
>
>Certainly the obligation, in any contract -- especially in construction 
>contracts -- has a lot of legal and factual significance. It would be 
>good to try that out on a few contracts. A lot of what contracts will 
>turn out to be are a bunch of obligations. (There will be other stuff 
>as well.)
>
>I was trying to see if obligation is a high level item that would 
>contain other items like payment and notice.
>
>Governing law item is what I would think of as a boiler-plate item. I 
>see that as part of a standard piece of verbiage. There are other 
>pieces that are in that category such as a merger clause, ("this 
>document represents the entire agreement...")
>
>DG: I call that an integration clause. Is that the same thing?
>
>RC: Fair enough. There is a severability clause. That states that if 
>one clause is found to be unenforceable it doesn't invalidate the 
>entire contract.
>
>The point is that the governing law item brought to mind that there are 
>several other items that fall into what I call the boiler plate items 
>-- even though that is not an artful term.
>
>Other items might be more specific to construction: the name and 
>location of a construction site, the scope of work, changes. 
>Construction contracts are a little more plastic than many other 
>contracts because of changes in the scope and changes in the price and 
>time. Construction contracts typically have built in provisions that 
>allow for those kinds of changes to be made.
>
>In working through the scenarios the question of warranties and 
>representations emerged as something that merits examination. 
>Representations are statements about existing facts. Warranties are 
>about future facts.
>
>In construction there are statements (representations , or more often 
>warranties about a  set of future existing facts) that bring with them 
>legal obligations, but are not obligations in and of themselves.
>
>With respect to dispute resolution... we took provisions from a bunch 
>of construction contracts (with Zoran). I think Zoran has done a good 
>job of doing that. Litigation, and arbitration are legally binding. 
>Mediation and negotiation are non-binding forms of dispute resolution.
>
>The scope of the dispute that is subject to a form of dispute 
>resolution is defined or described in the clauses. Sometimes the 
>procedure is also described. For example, the American Arbitration 
>Association has different procedures for different industries. Many 
>times a well drafted dispute resolution clause will describe what set 
>of rules to follow (using those from the AAA or some other org)
>
> From all of that, another area bearing more consideration, is looking 
>at how markup of dispute resolution provision might be integrated with 
>other items - such as the notice item.
>
>Zoran: It is a good point about integration of other items. We think of 
>the breach event as a common concept. When there is an obligation there 
>needs to be some event to be checked against.
>
>These are specialized concepts that need to be checked against
>
>Rolly: When I was thinking about events and outcomes I was going from 
>events to outcome. And outcome as I was thinking about it, is a 
>conditional obligation. If this happens, then the outcome happens. 
>Zoran, you are suggesting that we should look in the other direction as 
>well. How are obligations met or fulfilled.
>
>In the process ...
>
>DG: You put a note that you wanted to further clarify the distinction 
>between event and condition...?
>
>Rolly: Yes. For a fist pass I didn't make the distinction. I called 
>everything an event. But it would be possible to call events that give 
>rise to an obligation versus ..
>
>DG: For conditions, when you look at automated processes or automated 
>rules that might trigger a notice or something... having the system 
>know what these conditions are and know how to apply them would be 
>important. But that may happen at the application level. I'm not sure 
>what needs to be encoded in XML.
>
>I could imagine that applications might know what events trigger other 
>actions... I'm just sharing with the group my thoughts as to what 
>should be in the standard
>
>Zorin: One way is to think about , for every item, why capture this. If 
>it is for search or management then we need to capture that as an event.
>
>Condition can be used for search and for management. Condition can be 
>used to monitor things at runtime. Is that too abstract?
>
>DG and Dr; Leff: Yes.
>
>Dr. Leff. The AI and Law community has discussed events triggering 
>obligations. You also have a workflow perspective.  There you are 
>looking at one event triggering another. And you are looking at the 
>kind of thing a computer would know about. But without an XML event 
>that corresponds to a notification then the computer can't know.
>
>DG: Thanks. That's helpful.  On the change orders that you mentioned 
>earlier, are you envisioning that the change orders themselves would be 
>electronic documents... or would those continue as paper...
>
>RC: I'd envision them as being electronic.
>
>DG: And how would they be referenced to the original?
>
>RC: I don't know. But I would think that there would have to be some 
>association of the change order with the original agreement. There is a 
>whole procedure for getting sign-off and doing this in the paper world. 
>Some way to mimic that electronically is probably in order.
>
>DG: There were big scandals here in Massachusetts (that I was not 
>involved with -- for the record) associated with not managing change 
>orders on the 'big dig'. Change orders were being sent in and approval 
>was not part of the process.
>
>Would there be not just signature, but approval of change order element?
>
>RC: There would need to be something that would describe the change 
>order. I don't know if signature and approval elements need to be 
>distinct.
>
>Imagine if during the big dig the contractor hits rock instead of dirt. 
>You don't want to delay the project for the weeks that the approval 
>process will require. So, typically, the contractor goes ahead and 
>takes the risk without knowing what the change order will look like.
>
>DM: By automating change orders and approvals the process can be sped 
>up considerably - thereby reducing the risk the contractor is taking by 
>continuing the job. After all, he is only going to be continuing for, 
>say, 1 week before he knows if the additional work will be approved 
>instead of, say, 4 weeks.
>
>Dr. Leff:  Change orders exist elsewhere. My university union 
>collective bargaining has those issues.  Those mechanisms are also 
>being discussed in eBXML.
>
>Zoran: What part of eBXML are you referring to.
>
>Dr. L: The business process specification has a way of doing that.
>
>RC: I was going to add before that I had spent some time looking into 
>other efforts that are under way to promote the use of XML in 
>construction contracts.  It appears that efforts are VTC construction, 
>an ITC effort backed by the govt. of Finland, or some university there. 
>There is an effort (eLegal) out of the UK that is looking at developing 
>XML tools for contract authoring and negotiation.
>
>The AEC(Architectural Engineering and Construction) that is proposing a 
>vocabulary for data elements for administrating and marking up 
>construction contracts - for payment purposes for example. There is 
>markup for different systems (heating, electrical building materials) 
>etc.
>
>I just raised this because it drives home that whatever we do we must 
>allow these other vocabularies to be used. We do not want to recreate 
>these other vocabularies.
>
>JM: Do non-AEC members have access to that information?
>
>Rolly: Everyone has access. I'm happy to send you the URL.
>
>DG: They are dealing with cad-cam stuff. They have dealt with bidding 
>(RFPs and proposals) and the other big part deals with subcontractors.
>
>Rolly: There is an emphasis on creating what they call a virtual 
>enterprise. This would be web based and all of the participants on a 
>construction projects would contribute.
>
>Zoran: I have a question.  How do you deal with multi-party contracts.? 
>Do they always reduce to many bilateral contracts?
>
>RC: The example that comes to mind is not from construction but from 
>partnerships. All of the partners are agreeing to whatever the 
>partnership is. In the construction context multi-party agreements are 
>unusual. It is generally 2 party.
>
>Zoran: And a bunch of subcontracts...
>
>RC: If surety bonds are issues then there are other parties that are 
>the beneficiaries of the contracts. I want a bonding company with deep 
>pockets that will promise me that if my contractor goes out of business 
>then they will pay to get things finished up.
>
>Dr. Leff: The business ... the trend that I am picking up is that multi 
>-party agreements reduce to bilateral agreements.
>
>DM: That was our conclusion at Fujitsu- without the benefit of higher 
>mathematics to support our conclussion.
>
>RC: That seems counter intuitive, but I won't say no.... (Still, if we 
>enter into a partnership between all of us it is not clear how that 
>reduces to bilateral agreements.)
>
>DM: It reduces to N*(n+1)/2 bilateral agreements. Though this m,ay not 
>be practical in the paper world, it should be no big deal in an 
>electronic world.
>
>RC: Next steps would be to refine the scenario and incorporate some 
>references to other work.
>
>DG: Is it worth contacting the AEC folks
>
>RC: Yes. I think it would be good if we had more to offer, but I think 
>it would be good to reach out to any of these groups in any case.
>
>DG: I'm sure that if we were up front and told them that we were in 
>knowledge acquisition mode they would respect that.
>
>RC: Yes. I think it is important that we make sure that our XML 
>standard support the use of these standards.
>
>Dr. Leff: The IEE (not the IEEE) had some work going back to '95.
>
>DG: Would you mind sending out a list of folks that we might want to 
>liaise with?
>
>DG:  Sure.
>
>DG: Do you have more?
>
>RC No. I think I hit the high points. It is useful to go through t he 
>exercise of marking everything up, and seeing how it fits into the 
>dispute resolution issues.
>
>DG: Thanks Rolly. That was great. What's the next scenario on the 
>agenda for the next call?
>
>Dr. Leff: The next scenario to cover is the data consortium.
>
>DG: John, will you be ready for that?
>
>JM: Yes, I will.
>
>RC: If I could add, postings about the scenario are quite welcome...
>
>DG: It would also be useful to take the good abstract work that has 
>been done and seeing how it applies to actual transactions.
>
>Zoran: Is he suggesting that we come up with a meta-model that would 
>find relationships between these data elements .. a breach event is a 
>special kind of event.
>
>DG: That'd be great.
>
>The AECXML web AECXML.org site had some excellent use cases. Very clear 
>and easy to understand.
>
>Dr. Leff: There are many formalism that might be useful. UML and others.
>
>DG: Anything further?
>
>JM: I thought we might talk for a moment about the clause model...
>
>DG: We were hoping to keep the meeting to an hour. Perhaps that should 
>be on the agenda for the next call. Do you want it on the agenda... it 
>could eat into your time for the call....
>
>[scheduling discussion]
>
>[meeting adjourned]
>
>
>
>
>
>
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_workgroup.php
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]