Minutes Draft July 2 - v1

[Dave Marvit <dave@marvit.org>]

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]