[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
Folks, Here are the draft minutes from our June 4th meeting. Please pass any corrections or clarifications my way. Thanks, Dave Marvit dave@marvit.org ------------------------------------ Draft Minutes OASIS LegalXML eContracts Technical Committee June 4, 2003 Conference Call. Summary: - Minutes of May 21, 2003 meeting were approved. - Extensive ‘high level’ discussion of Jason and Peter’s “Requirements for Clause Model” document. - Motion approved to “…close general discussion on this matter and go directly to a vote on adopting this document as the general guideline for the purpose of generating our structural model. It is noted that this supercedes the tentative agreement reached on April 9th. - Discussion on generating some kind of published proceedings to be distributed at the face to face meeting in Sydney, and possibly elsewhere. More information is being collected. ------------------------- The following were present: Rolly Chambers Charles Gillam Dan Greenwood Jason Harrop Jim Kane Dr. Lawrence Leff Dave Marvit John McClure John Messing Peter Meyer Zoran Milosevic Greg Wiley First agenda item: Approval of May 21, 2003 minutes 1 abstention (Dan hasn't read them yet, so he abstained.) All else in favor of approving the minutes May 21 minutes approved Next Agenda Item: Clause Model discussion Jason; I recently posted a requirements document for the clause model. That came about because on May 1 Dan posted to the list an email called 'proposed process'. The TC endorsed that process. The relevant part was that we would put together a requirements document for the clause model and, once achieved, we would seek consensus on the clause model. On 9 April we agreed to have a hierarchy going article, section, paragraph. After reaching that agreement there was some disquiet on the list (from John McClure, Peter Meyer and others) saying that this was not sensible. My email was an attempt to address those concerns. The doc was an attempt to provide info on that more complete view. It draws heavily on Peters May 7th scenarios. The philosophy is quite simple. It boils down to the following: For us to be successful as a TC the XML model for contracts needs to be widely adopted and widely used. This will only happen if the XML contracts format is used as an exchange format. (If it is just used internal to law firms and corporations then it won't be used as widely.) We get the widest possible adoption if we get the widest possible adoption of the clause model. This happens if we make it easy for people to use, and if people are able to use it for other business documents in their organization. People in law firms draft not only contracts, but minutes, letters, and so on. The argument is that it is unreasonable to expect people to use an XML model for drafting contracts and a different set of tools for drafting other document types. It flows from that point that they shouldn't have to learn another set of DTDs. So, if they are going to want to draft contracts in XML, they will want to draft other docs in XML and use the same tools. There is no magic here. This has been discussed for a while in the legalXML community. I would like to have a high level discussion about the philosophy behind the requirements. If we all agree then I would seek support for the vision statement of the requirements doc. Dave: The obvious question is simply if including support for other types of legal documents represents scope creep? Peter: I don't think it is more difficult to add a clause model for contracts than it is for what has been proposed. Zorin: You are proposing that we work on law business documents. UBL (unified business language) exists. If you can cleanly delimit the scope then I'd leave it to the legal folks. If there is no significant increase in scope then I'm OK. Jason: The kind of numbered paragraphs that are used in contracts also exist in many other types of documents. So, the implication is that if we use more opaque terminology it might be applicable to many other types of documents. The thing that distinguishes this work from UBL is that they are working on shipping invoices and purchase orders. They are business documents, but they are not including numbered paragraphs. John McClure: There was also a discussion in the court-filing group about trying to cover a broader scope of documents. We are back to the discussion of weather we should be discussing clauses or specific tags. Peter: We have to look at who is going to use it. Will people want to adopt a court filing DTD and a contracts DTD? It is inconceivable (in my mind at least) that these would go anywhere. John McClure: I am also concerned about scope creep. I am concerned by the relationship between the work that we are doing and the work that they are doing. Can you, Jason, speak to that? Jason: John is talking about the open office TC. That's the TC that has a mission to define a DTD suitable for use in word processors. It took as it's starting point the 'star office' system. They are well on their way to completing their first pass on the spec. It is expected that they will come out with a file format for Word processor. We can expect it to have the support of everybody but Microsoft. Basically what they are doing is coming up with a file format for word processors. You will be able to create any type of document you like, contracts, novels, love letters, and many other documents. The point is that they are not trying to capture the semantics of different types of documents. They are trying to capture in XML what word processors have been doing for many years. They are trying to capture structured numbering systems. What we are trying to do is to create an XML system that will be as easy as possible for people to use. The kind of XML you will see coming out of the open office TC is not the kind of XML that end users will ever want to expose themselves to. I see them as different efforts. Nevertheless, the clause model should be able to be easily converted and opened in a compliant word processor. Peter: Would it be fair to say that the open office format would be like an XML RTF? Jason: Yes, that's exactly right. I'd be reluctant to cal it that because Microsoft's new system is an XML RTF. In the open office TC hierarchy is not given the highest priority. McClure: I am concerned that in law people will try to gravitate to open standards. This implies a separate set of tools. Is that right? Is there a way for us to have our standard fit into the open office tools? Peter: If these guys get traction then you will see word processors using XML format. But that leaves the question about how people will be able to get the XML automation benefits. To do that you need to be able to represent the hierarchy. Getting into the market is has to be evolutionary. John Messing: It seems to me that we have a couple of issues. If we develop a DTD for contracts, will it be exclusive of the other work being done by other groups (like leXML and the work being done in Europe). Then there is the question about our working with the XML word processors. Is anyone working in this group part of the open office group? If we have such a person we should find out if we can pass a DTD to them and load it in. DG: There seems to be a general appetite for more liaisons between our group and other TCs. Jason: There are two major word processor file formats. One of course is MS word. The other is open office. The new version of MS Word has an XML file format. Today, only MS Word understands it. But it will have another capability (Word 2003 is in beta release) to be able to read in any W3C DTD. So we don't have any issues there. People who want to read a legal XML doc in MS word will be able to do so. The thing about open office or star office is that the current version is going to be less functional that MS Word because it can only read in open office XML. It cannot read in other XML document types. The question of reading in a Legal XML eContracts doc becomes a question of conversion. If you want to open an eContracts doc in open office you would take a style sheet and convert it to open it in open office. John McClure: How is it transferred OUT of open office in to LegalXML? Jason: I don't see why you'd want to do that. It is like converting from any other legacy format. John Messing: In defense of john, if people are going to be writing docs in these then it needs to be able to export docs that are both valid and well formed against the schema. Jason: That's true. But we have focused on two tools [star office and MS Word]. We are assuming that there will be additional tools using the open office format. But we haven't discussed the myriad of other tools that people will use. That's both the existing XML editors and the ones that are being created. It's just that one of the systems (open office) can only handle one DTD. That's a shortcoming of that system. But there are many other tools. John McClure: The answer that I might expect from MS is that they do preserve and respect XML namespaces. If we wanted to markup their doc with LegalXML it can live inside their containers. My concern is to hear that the notions that are important to represent in a contract are already being represented in open office with the semantics drained from them. Getting rid of article - section - paragraph- as an attempt to create a do-all object will ultimately work against our desire to create a DTD that is meaningful and easy to use. It will ultimately have the effect f driving people away from us. People will expect to see article section... Jason: Well, they expect to see meaningful tags. We know that article section paragraph mean some things to some people and different things to other people. What we are proposing is having a hierarchy that won't have that problem. In section 5 of the requirements doc we conclude that the term clause is radically meaningless. Using the term is a recipe for misunderstanding. The only way (we concluded) to come up with a DTD that people will know and use is to avoid use of those terms. Rolly: For me it is useful to have the type of hierarchical structures as envisioned by the clause model. But as long as it is something reasonable I can live with it. I also don't feel the driving need for a 'one size fits all' model the way some others do. I don't raise that as opposition to what has been proposed. Wherever this leads it will be useful. John McClure: Is the goal of the paper that was published to revisit the consensus that was reached? Jason: I fully expect that we will have a hierarchical model - in the sense of elements nested within elements... Weather those elements have the same name or different names, the answer is yes. The goal is to have a fresh start. DG: I have a general comment. I like everything in the doc that you put forward. Having contracts in scope is necessary. Broadening the scope is nice, but not vital. When I think about the example you are using it doesn’t seem as a practical matter, to broaden the scope that much. John McClure: I am a bit disturbed that you agreed with most of the content of the doc. This is a radical change to the consensus. I didn't think we were going back to consensus that had been agreed to. DG: From a process point, we did have a ‘going – forward’ straw man. We called it a 'tentative agreement'. I agree that once we have a consensus we'd better have a VERY good reason to revisit. We are not, in this case, reopening the matter. We only had a tentative agreement. Jason: The reason we agreed only tentatively was that the tradeoffs were not yet clear. Then, after the call, there was considerable traffic on the list that indicated that article section paragraph was no the be all and end all. DG: If that's agreed to, and I believe it is factually correct. Getting into the details, the fourth paragraph states that we need to capture the hierarchical rendering in some way. I took that to mean that we are still there. We still need to capture the hierarchical quality of the data. Jason: That's right. The big difference is the names. We need terms that people will understand, but that they don't have meanings associated with the terms applying to a specific level. We think that by making it slightly less contract specific we don't lose much but we gain a heck of a lot. John McClure: My understanding of the tentative agreement reached was that the terms article, section paragraph were not. There was concern about the number of levels. Jason: You capitulated on the use of Article. We didn't want everyone outside of North America to capitulate as well. Irrespective of the answer when dealing with contracts, the application of that hierarchical model [article, section, paragraph] to the realm outside of contracts is inappropriate. This application is significant enough to make us reconsider the application of these tags. John McClure: There are many ways to deal with internationalization. Since we can qualify these things by different countries we may be able to address the naming requirements of different countries by having different DTD for each country and having transforms between them. DG: Can we tighten this to something that is poll-able? Dr. Leff: If I can add... there is a lot of work going on. There are several vendors of legal document assembly that might be useful to look at. On the subject of numbered paragraphs, doc-book supports that. As for parameterized clauses … [resources available on the web site] DG: Is it possible to reach closure on this? I'd like to do a quick straw poll. I would suggest voting on the specific requirements in section 7 John McClure: I'm not comfortable with this yet. This will have changes that will ripple through a lot of the work that has been done. Peter: We will have a structural hierarchy, but the names are unclear. The hierarchical issue is not in dispute. DG: Does that address your concern? John McClure: I am saying that this document is incomplete. I don't know what the names are going to be. Jason established a format that we are all supposed to follow. DG: John you have made your point. Zorin: There is a difference between a vision statement and a requirements doc. I am a bit concerned if there are some consistency issues. Jason: I put the vision in part 1... DG: I have some particulars as well. But I would rather have a first vote on weather or not to end discussion. The distinction I am making is between general open debate and a vote… DG: I move that we close general discussion on this matter and go directly to a vote on adopting this document as the general guideline for the purpose of generating our structural model John McClure: I'd like to amend it. I'd like to add that this invalidates the general agreement reached on April 9. DG: as opposed to invalidate, I'd say supersedes rather than invalidates. John Messing: The doc seems to be trying to integrate the work of court doc 1.1 and building on top of that. Do I have that right? Peter: It is more an issue of considering that work, not adopting it. DG: I move that we close general discussion on this matter and go directly to a vote on adopting this document as the general guideline for the purpose of generating our structural model. It is noted that this supercedes the tentative agreement reached on April 9th. John Messing seconds: All in favor: John McClure and Jim Kane voted no. No abstentions and the rest in favor. (Missing Greg who had apparently left the call.) The motion passes 8 : 2 DG proposes that people work to provide amendments by email. Then we can vote on it. Then this will become our first official work product. Rolly's scenario will be discussed next week. Further action on this matter is deferred to the list and vote at the next meeting The next issue was the dispute resolution and construction contracts. I'd suggest we defer it on the basis of time. Dr. Leff, so I should put these on the agenda for the next meeting? DG: Dr. Leff, can you post the agendas going forward (including slippage..) New business: Jason: We have a room for the Monday and the Tuesday at low cost to the TC. I need to know if anyone is not planning to go to the conference DM: I may not go to the conference Jason: So I'll get that issue clarified. DG: Thanks Jason. And on the ABA meeting... we are on hold until our next meeting. [Discussion of the probable dates of our meeting…] DG: So we should hold Thursday through Sunday morning of that week. (Aug 7th through the following Sunday.) DG: Dr Leff has made an interesting proposal for the work of the TC.. Dr. Leff: We could just have our own proceedings. Someone (the editor) could collect a document from each person submitting - and hand it out at the meeting. Possibly send it to some libraries. Another possibility would be to submit something to a publisher - such as MIT press’s “Journal of Markup Languages”. The people who have submitted papers and possibly someone else, could submit. Then we'd have our editor to review... DG: I thought that was a great idea. Not only do we have great IP here, but also there is nothing like a publishing deadline to get people motivated. Jason: Will we have work product by then? We don't want all of our papers to be speculative. DG: It remains to be seen. Dr. Leff, also, people from outside of the TC can contribute. DG; That won't be the worst thing in the world. People here have interesting things to say. It would not bother me to have a robust published dialog prior to actually having a work product. Dr, Leff: Should I send a letter to the journal of markup languages inquiring? Peter: I think that the journal isn’t publishing anymore... DG: Why not submit a proposal describing what would be involved and where we might be published? Dr. Leff: There is no commitment incurred by inquiring. DG: Do people think that's a good idea? Hearing no objections, please go ahead. And if people have favorite journals, please email them to Dr. Leff... DG: Thanks to all. We meet two weeks from today at the same time. Meeting Adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]