[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes Draft from the OASIS Legal XML Member Section ElectronicContracts Technical Committee - Take 2
|
Folks,
I received a change to the minutes form John McClure. It is incorporated below, and marked with *** for easy review.
Thanks,
Dave Marvit Fujitsu Labs of America dave@marvit.org --------------------------------------- Minutes OASIS LegalXML eContracts Technical Committee May 21 2003 Conference call
Summary: - ODR and Construction Contracts were moved until the June 4th call. - Dave Marvit was unanimously elected co-vice chair. - The ABA will be appointing an OASIS representative in early June. This will create an administrative contact we can work with. John Messing will send email to the list when that happens. - The minutes were approved subject to the revision that on July 16 the law firm contract creation and negotiation will be discussed. - Dr. Leff presents his 'click-through contract' scenario. - It is agreed that John Messing, with Dan's help, and possibly Rolly's help, will work on a scenario for electronic conflict of interest detection and management. - Dan moved: We should indicate: "For every issue we surface we will determine if it is transactional or it relates to the contract content. The assumption is that we will be biased towards contract content, but will keep track of the other data. We will explicitly make the decision as to what will be included in the standard at the end of the scenario review process." Dr. Leff seconded the motion and it was unanimously approved. - Proceedings, ABA and San Francisco discussions were deferred until the next meeting. -------------------------
Body of May 21, 2003 Minutes
The following members of the committee were present:
Zoran Milosevic Jason Harrop Dave Marvit Dr. Leff Peter Meyer Barry Hansen Dan Greenwood John Messing John McClure Sergio Maldonado
Note: Because Rolly couldn't make the call, the decision was made (by acclamation) to move the discussion of ODR and construction contracts, to June 4, and move the contract litigation to the end of the queue. Dr. Leff's click through contracts will be added to today's agenda as item #3.
Dan Greenwood nominated Dave Marvit to be the successor to Eddie O'Brien as Co-Vice Chair. Jason Harrop seconded. The motion was unanimously approved
John Messing: (Interjecting) The ABA will be naming an OASIS representative around mid June. When that happens the representative will have a staff person to help them. That should facilitate coordination.
DG: Could you send us an email when that happens?
John Messing: No problem.
Approval of minutes:
Jason: Could the minutes be amended to indicate that on July 16 the law firm Contract creation and negotiation will be discussed?
Dave: Sure
DG: We can vote on minutes as amended, and then send it to the list.
DM: So moved DG Seconded Approved by acclamation
DG: Up to now we have done administrative work. Finally, we move on to substance. Finally... Dr. Leff...?
(Dr. Leff presents his Click-Through Contracts scenario) Dr. Leff: We have prepared a DTD for handling click-through contracts. We have all been to web sites, gotten agreements, clicked 'I agree' and downloaded software.
We have collected some examples of these agreements and abstracted out the key points someone would want to search for.
The first question is why do this in XML? If a corporation has a lot of people downloading software and clicking on contracts, they are obligating the company. The company would want to know what people are agreeing to.
There needs to be some signed applet that stores the contracts locally, and there must be a system so the lawyers can search by clause type on the contracts to which his company has agreed.
An actual DTD is out there. It includes terms such as the name of the software vendor, name of software, agreeing party. There is also a preamble and a substance section, a choice of Law, liability waiver, and some specialized tags (such as munitions control and internal use restrictions that only apply if the US government downloads and do not apply to anyone else).
All of thee tags have been put into Jason's format, and are in the documents folder for the TC.
The scenario is that people will be downloading these, agreeing to contracts in XML, the applet will be putting it into special places on the hard-drives, and then the data will be searched by the corporate council - so they can find out what agreements have been made.
John Messing: So this is for reporting and data-mining the obligations and ramifications of downloads by the corporate community?
Dr. Leff: Yes
DG: It is maddening not being able to certify how many or what contracts the corporation, or government organization has been obligated to. Also for consumers and small businesses, they should be able to know and keep track of their obligations. Now it is hard to even know how to save this stuff. So there is a bit of a consumer and small business angle. Still, the big corporations will be the driver.
John Messing: There might be other applications. This could cover any type of agreement. For law firms (for example) this kind of model has applications in conflict analysis... A big firm has to make sure that a new client is not in a conflicting position with another client. For large firms this can be tough. A litigation client requires a fairly complex conflict analysis.
Imagine that Dr Leff sued you, Dan. He was represented by a partner in my firm. At another time, Dan sues Dave regarding an entirely different matter. But we can't represent Dan because that's a conflict with Dr. Leff.
If you get into an online consumption and provision of legal services -click wrap or something more sophisticated - keeping track of the conflicts can be very difficult.
If the law firm takes on both matters then it might have to get out of both matters.
I suspect that there are other applications as well.
Zoran: Can we specify these patterns of conflict?
Dr. Leff: Doesn't the law case management systems that already exist have the info required to handle this? I understand how important this is, but does XML need to be involved? We only need the XML if heterogeneous systems are involved.
John Messing: My point is merely that the opportunity for data-mining of contracts in real-time has applications well beyond click-through contracts.
Sergio: This seems like a good choice because click-through contracts are very specific and nicely extensible.
DG: The idea of going through each scenario is so that we can do factual analysis so that we can set requirements wisely. I think it would be a good approach if you, John, put together a separate scenario for the issue of conflict management.
John Messing: Rolly would know more.
DG: Sure, but could you champion it. I'd be happy to help out. As for the click-through contract situation, there is a great deal of similarity. There is a different group of contracts for representation that are similar to one another, but quite different from the click through contracts. So, it would be helpful if they were a represented in a separate scenario.
Jason: I thought that the main point that John was making was NOT merely taking care of all of the conflict searching, but the intersection between conflicts and online business services. When you offer services to everyone who might go to your web site -- say John Q. public who wants a $100 divorce -- this is where you need to do the conflict analysis. The customer may agree to the terms of service. Then you need to do the conflict analysis.
John McClure: Does the scenario have anything to do with presentation of the contract?
Dr. Leff: Yes and No. We are assuming that the presentation will be a function of the XML. We do provide a facility for the company to go from an ASCII format into the XML format. In essence we are dealing with an ASCII presentation format. In our case we are going from a realm where there already is a presentation and going into XML.
John McClure: So is the contract stored in XML?
Dr. Leff: Yes.
John Messing: Is the tool being used (the applet) outside the standards process?
Dr. Leff: Yes, of course. We provided that in the scenario for context. The conversion is not intended to be part of the standard, or an issue for the TC.
John McClure: How do you describe the information model that your tags describe?
Dr. Leff: It is not so sophisticated. It is basically a sequence of tags. It does not have the complexities of conditional relationships and temporal relationships between clauses.
DG: Putting my hat on as government council - a lot of the contracts have the same title. As corporations collect these it becomes an issue to be sure that as hundreds or thousands of these are collected it becomes important to have a unique identifier for each contract.
At least within the domain of implementation, the company needs a unique identifier. I am not so concerned about the implementation now.
Also, we will need some date to be specified.
Barry: Does that need to be in the standard, or is that a function of the software that puts the date there? Is the execution date (and the stuff outside the contract) in scope or not?
DG: I don't have an answer, but having a date in most contracts is standard, But these are contracts of adhesion. We will probably need to support signatures and dates in some way -- even though they aren't represented in all kinds of electronic contracts.
Jason: It is a fact that is there in the background. The scenario clearly needs the time and date the person clicked on the contract. There is an overlap between this scenario and the contract management scenario. We can all agree that the time should be noted, but it does not necessarily need to be part of the contract.
DM: What exactly is a contract?
Jason When you say you agree to a click through contract you agree to what you saw, not to an underlying XML representation. If there is a dispute and there is a question of the time, well, that's an issue of fact. Typically the date thing is outside the representation of the contract.
Peter: The date is when you installed the software in some cases. In those cases it becomes a question of fact.
Zoran: It helps to see the time and the signature as evidentiary because the contract exists independent of them. They exist as evidence of the agreement, but the agreement exists independently of that.
John McClure: But it can be very helpful.
Peter: We need to figure out what should be in the standard. There are an arbitrary number of pieces of additional information that might be included. So what is in or out of scope?
*** John McClure: There is a distinction between agreements and contracts. Agreement only occurs when all parties have signed. So any single party's signature or signature date on an agreement does not tell you when the contract has been agreed to.
Zoran: I think we are talking about differing things. There is contract template and contract instance.
Barry: I have been following this and I think I didn't express this well. I was thinking that the date is not included in the representation of what I clicked on. So, when we think about scope, are we dealing with other pieces of data that are not necessarily part of the contract? For example, we keep info on the location of the paper copy. (Such as 'filing cabinet eight on the third floor'.) That wouldn't be part of the standard, but it is useful metadata. It is relevant data, but I wouldn't expect to see that as part of the standard. So, with this in mind, how broad is the scope?
DG: It seems that from the scoping discussions we've had so far... we want information on the contract formation side that goes beyond the contract itself. Also, on the contract management side, we want information which goes beyond the scope of the contract itself. So I feel comfortable including this.
John McClure: Can we solve this problem by allowing other standards based XML tags into the standard? If the problem is addressed by another standardized namespace, why not use that?
DG: I'd like to keep going on the scenario. We've got the parties; we have the terms and conditions. Does anyone object to splitting off John Messing's law firm example off? (No objections heard.)
DG: Then we got into the idea that there should be a unique identifier for each contract. Then we agreed that date and time are useful, and that many people would want to include it. But there was also a view that it was out of scope.
Then the question came up 'What is the contract itself?' That is a big issue in terms of this scenario.
The final thing I'd add is that it would be useful to have a more granular markup. What is the return policy, what is the revenue recognition and so on.
Ought this standard assume 1. that the contracts are like a blob (an HTML or PDF document) and people would download them in that form and XMLify, or that 2. the users would put them into XML, or that 3. the big company would be putting the contract into XML with this DTD to begin with?
Dr. Leff: The software has already been written to put the contract into XML from ASCII. The software makes no distinction as to who does this.
Sergio: This is a very good application. Much as we now have P3P for privacy, this could apply in a similar way. The question of do you sign the image or the essence. There is a lot of scope for that discussion.
DG: The P3P perspective assumes that one use would be for the web site to put the agreement into the XML format. Should we think that's the only way? Or would there be other ways for people to apply this?
Sergio: We can't assume that everyone will be putting their contracts into this format. There may be a role for intermediates here.
John McClure: If we were to adopt the court filing envelope that might contain an agreement.
John Messing: Court filing 1.1 is being abandoned for 'court filing blue'. The issues of merging with some of the other standards (court filing TC) will be tricky, but are in the air.
You'd have a base 64 encoded representation of the 'blob'. You sign the blob using XML-DSig. That's one way.
DG: How about the e-notary TC?
John Messing: No, that committee has been in mothballs for a while. And before it was mothballed, it was still not appropriate.
Jason: It seems to me that the way that is likely to work is that, for a while at least, the XMLization is likely to happen at the vendors end. The licensee is likely to see an html or text document. Only after our standard is established will the licensee generate demand to receive the contract in XML.
More generally, I'd question the idea that the corporate council wants to see all of the licenses that the employees have agreed to. Right now the councils don't want to know because there is a question of agency. Imagine that I work for Mercedes and I get a click-through contract that says I will forgo all patent cases. Well... Mercedes isn't going to grant that agency. The corporation doesn't want to acknowledge that it is bound by all of these contracts.
It will more likely be: I Jason Harrop, want to agree to the following contract, but before I do it has to be signed off by someone who has the appropriate authority. If it is benign then perhaps software can decide and I can sign off myself.
DG: I take your point. Triggering a process, for approval or something else, would be useful. But still, I'd want this kind of system. If I've been informed of an agreement then I can send off an email message repudiating it. While I know what you are saying, I think your statement that it is the only way it would be implemented is too strong.
DG: Our final work product hasn't been determined yet. But in my mind I imagine that we will be producing some kind of implementation guide that will help with these tough issues. For example, if date and time don't make it in then we will be able to address it there. The point is that we will be able to address issues without including them in the standard proper.
Jason: I think we need to specify which bits of scenarios will be addressed in the standard and which parts will be addressed in other surrounding materials.
*** John McClure: I agree that there will be certain workflow issues. This can be addressed by having a document representing the draft separate from that for an offer separate from that for a contract. The offer documents can be of two subtypes: offer and counter-offer. The point is that there are different document types. We could say that a legal contract is represented inside a legalXML envelope. This would necessarily be a presentation format. Whereas a draft and offer document doesn't necessarily have a presentation form.
DG: Jason suggested that we should provide an indication as to weather the business requirements should be encompassed inside the standard or outside. The idea of triggering a workflow is an example of something that should be outside the standard itself.
I would assume that the unique ID would be inside the standard.
Second is date and time: I think we need to return to that. We have it tagged as an issue and I personally don't have a conclusion. I think that's unsettled.
The other two are: - An accurate representation of the contract and
- A markup of the basic sections of the contract.
Jason: I'd put the unique ID in the meta information bucket. It could be in the wrapper or in the contract document somehow. I would think that a unique ID for a contract is not part of the contract in any legal sense.
DG: I am comfortable with your characterization, but I still think there should be a tag providing a unique ID for each file.
John McClure: Are we exchanging an agreement? And if so...
DG: At the point agreement is manifest, then that needs to be captured (what was agreed to). There needs to be an ID for that.
John McClure: The identifier you are referring to, is it for the document exchanged between the vendor and the customer? Or is it for the contract? If there is a purchasing contract that this is made subject to...
DG: You mean other documents incorporated by reference?
John McClure: Yes
DG: You think that there should be an UID for every agreement?
John McClure: Yes
DG: Hmmm... Ok.
John McClure: I am trying to make a distinction between an agreement and the contract.
DG: What I'm saying is really simple. I go to a site and it has 18 paragraphs. Why isn't that a contract? What else is there?
McClure: The web page represents the document that is being assented to. The identifier reefers to the web page (the URL for the web page)?
DG: Oh... I am talking about just the contract itself. I download a web page that has text inside a scroll-box. You should be able to get just the text inside the scroll. I'd like to have a UID so I can look at that contract later -- know what it is that I'd agreed to. Is that responsive?
Dave: Are you suggesting that the ID be globally unique?
DG: It wouldn't bother me if the ID was not globally unique.
Jason: It would be quite useful though. Imagine two large organizations merging. It s preferable if the identifiers have a good chance of being unique. We have to ask 'what is the business requirement for doing so?'
DG: I have noticed that many of these documents [click through contracts] have the same name. I want to be able to see, for example, who the parties are.
John Messing: The question is how do we help people get useful information from the documents. A document ID could be useful in many ways, but we need to be able to have the specific business case.
Peter: We seem to be talking about the markup of the terms of the document (that will become a contract when assented to) and then the various kinds of documents representing the contract. Some times these documents will be a complete representation of the contract and sometimes they will not be.
How often will the XML markup remain relevant after the contract artifact is generated? I'd suspect that it will remain relevant only in limited cases.
The other thing that is being contemplated is having an envelope that is used when moving these contract artifacts about. This is quite a different issue.
I am wondering if this entire scope can be handled by one TC.
DG: I agree. I think that the purpose of the scenarios is to see if we are being under or over inclusive in our efforts. Do you think we should scale back to some representation of the contract at the time it was clicked on?
Peter: My personal view is that we should be focusing on the markup of the terms. If we try to do more we will be too far ahead of the technology and the market. We will end up as an interesting piece of academic work.
DG: I don't disagree with anything that was said, but I'd like to hear other views.
John Messing: I tend to agree with Peter. The discussions are so interesting I tend to get lost. I think it is important to remain focused on the objective.
DG: Perhaps we should be applying Jason's razor to keep defining what is inside and outside the contract. Then we can decide later what to include.
John Messing: Yes, but we need to be careful that we don't do something useless. We can keep two separate lists. We can keep a list of what is inside and a list of what may be required outside. Then we can look at the stuff inside and work on an agreement. Then we can examine the outside terms and decide what we need to include.
Peter: That seems spot on.
DG: That is appealing because I feel like we can actually achieve something this way.
Zoran: I like Jason's original proposal - some information is common to most contracts (names, parties). Resolve that and then get into implementation choices.
DG: It sounds like everyone who has spoken believes that we should stay as focused as we can on the contract itself.
Dr. Leff: 1. The whole issue of the transportation of the contract - this was reviewed by the secure contract container. (More information is available on the resources page). 2. The other scenario I sent out, litigation and eContracts, looks at the relationship between the contract and eBXML. That is an interesting issue. When we get to that scenario it might be a good time to look at that issue.
On the GUID issue, at least in the case of the click through contract, the title may be the same, but the product name will be different. (Think about the same lease being used for different addresses.)
DG: Before we get to that, can I see if there is agreement on the basic scope question. Do people agree that there should be basic focus on the content of the contract itself? Does anyone disagree?
Jason: I am wondering weather the question should be weather we give the envelope description to a different committee, or hold on to it for later. If nobody has a need for it now then it is reasonable to hold on to it. On the other hand, if people need it now, then we can pass it on.
Peter: Let's hold on to it for now. Let's keep track of the 'transactional' data.
DG: A motion might be ripe. Maybe we should indicate: For every issue we surface we will determine if it is transactional or it relates to the contract content. The assumption is that we will be biased towards contract content, but will keep track of the other data. We will explicitly make the decision as to what will be included in the standard at the end of the scenario review process.
DG: Moves Dr Leff: Seconds
Approved unanimously.
DG: In view of what we just said, I think the scenario gets a lot easier to define. The transactions and the license don't change. -The UID, date, and Time get tagged as transactional. (If there is a date in the content of the contract then it goes to the other side of the ledger.) - Transportation is clearly transactional. - The basic sections of the contracts (liability, choice of law, and other basic terms) are inside the content of the contract. - Finally we had the idea that there would be some kind of container. Perhaps we would model it on the court filing envelope, or an IETF standard. But we would have a container for the blob that would be the presentation form of the contract. This would be a representation of the presentation of the contract.
Can we leave the last point as open? ["Is the presentation transactional or content or something else?"]
DG: Perhaps we should open up the next meeting with the minutes and have the scenario in a votable form?
Dr. Leff: I am not clear on what am I supposed to do?
Dg: I was hoping that the group could decide if any given scenario is supported. That may require some reworking of the scenario.
Dr. Leff: So I should be trying to categorize the elements?
Jason: I am concerned that we will have another long discussion and not be able to move forward.
DG So how do we get closure?
Peter: By surfacing the functional requirements.
Dr. Leff: Perhaps we should add another column to Jason's table. We may need to work off line.
DG: The only pieces that are not captured are 1. What types of parties are these, and 2. What types of contracts are we discussing within the scenario. Those are the only two that I recall...
We should probably defer the proceedings and the ABA an SF discussions to the next meeting.
Zoran: Any way we can limit our time to 2 hours maximum.
DG: Apologies.
The meeting was adjourned at this point.
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]