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