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: Minutes Draft July 2 - v2


Folks,

Here is the second draft of the July 2 minutes. It includes many
corrections courtesy of Dr. Leff. Because these were mostly
typographical I have NOT marked them with the usual '***'. (Thanks to
Dr. Leff for taking the time to do a detailed review.)

I will look forward to our meeting in a few hours.

Best,

Dave Marvit
Fujitsu Labs of America
Special Projects Consultant


--------------
Draft Minutes (Version 2)
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
lateafternoon for a face to face. (noon to 5 or so). More information on
avenue is pending. 


Starting the meeting: 

DG: I believe that our only agenda item is Rolly's scenario. 

Rolly:  I'll 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. I
fit 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 aw
hole 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's collective
bargaining agreement with its union provides a procedure for amendments.
Those mechanisms are also being discussed in eBXML. [Note: Dr. Leff
points out that EBXML provides for the association of XML documents in a
"conversation."  This would provide a potential mechanism for
associating change orders with a contract.] 

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

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

Dr Leff:  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] 





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