[legalxml-econtracts] Minutes Draft June 4

Folks,

I have received comments from John McClure and Jim Keane. They are incorporated below and noted with *** to make it easier to compare this version of the draft minutes with the version sent out earlier. As always, additional comments or corrections are welcome.

Thanks,

Dave Marvit

Fujitsu Labs of America

dave@marvit.org

------------------------------------

Draft Minutes (Version 2)

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.

*** - Jim Keane has posted some comments about the conference call that are available online at: http://lists.oasis-open.org/archives/legalxml-econtracts/200306/msg00006.html

-------------------------

The following were present:

Rolly Chambers

Charles Gillam

Dan Greenwood

Jason Harrop

Jim Keane

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 thought we were not allowed to continue a debate once a consensus had been reached.

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 concerns about the tentative agreement -- all raised in my posts to the list -- dealt with the naming of the levels, and the number of levels; my concerns were not about the hierarchical nature of the clause model. Generally, I was proposing that Paragraph be content that can appear at any of the levels, thus invalidating its use as a captionable item like Section and Article. Also, I expressed a dislike for a clause model that did not use the very-common term "clause" and used names like "Sub1Paragraph" and "Sub2Paragraph". In no way, though, was I questioning the tentative agreement on a hierarchical clause model. I was not at the meeting that reached the tentative agreement, but was very pleased to hear that the "recursive" clause model was not as attractive to the group as the "hierarchical" clause model.

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.

***[In a note received after the first draft of the minutes John McClure states that "Following this, I made a motion to table the straw vote, a motion that was improperly not voted upon."]

John Messing seconds Dan's motion:

All in favor:

John McClure and Jim Keane voted no. No abstentions and the rest in

favor. (Missing Greg who had apparently left the call.)

The motion passes 8 : 2

*** [Note: After the call ended Jim Keane posted an explanation of his vote to the mailing list. It is available at: http://lists.oasis-open.org/archives/legalxml-econtracts/200306/msg00006

.html]

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

legalxml-econtracts message