[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]