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 June 18 - v3



Folks,

Here is another revised version of the minutes based upon a last minute  
comment from John McClure.  Dr. Leff's comments remain marked with  
"***" while John McClure's comment is flagged with "+++" so it will be  
easy to find for quick review before the meeting.

Talk to everyone in a few hours.

Best,

Dave Marvit
Fujitsu labs of America
dave@marvit.org

--------
Draft Minutes (Version 3)
OASIS LegalXML eContracts Technical Committee
June 18, 2003 Conference Call.


Summary:

- Minutes of June 4th meeting were approved unanimously
- Some discussion about scheduling around the ABA conference
- Discussion about the requirements document
- Discussion about the need for the specification to not impede fully  
automated systems by requiring the ability to render
- Approval of the requirements document 9 to 1 with an understanding of  
the context generated by the discussion
- Approval of section 3.2.2 describing a process to develop a clause  
model (approved by all with 1 abstention).

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

The following were present:

Rolly Chambers
Dan Greenwood
Barry Hanson
Jason Harrop
Jim Keane
Dr. Leff
Dave Marvit
John McClure
Peter Meyer
Zoran Milosevic
Greg Wiley (as an observer)


Dan G: Moves to approve the minutes of the previous conference call  
(June 4th)
Seconded by Jason
Minutes approved unanimously

Jim Keane suggests that we add the ABA discussion to the agenda.
John Messing has scheduled an eNotary meeting on Wed and Thursday.
Jim has rooms set aside for Friday and Saturday afternoon.
Sunday there is an ODR meeting. We need to schedule around the business  
law meeting if we can.

DG Next item ďReport on Friendly amendments received.Ē JasonÖ?

JH: There is really only one amendment, and it is from Dr. Leff.

Dr. Leff: The application I suggested may not involve any printed  
display. (The information is being used between applications.)  
Therefore I proposed that nothing in the clause model should get in the  
way of the needs of people that donít want to display the contract. One  
suggestion is to make that change in the minutes [rather than in the  
document].

DG: I think it should be addressed explicitly.

DM: Why not put it in the doc?

JH: It didnít seem necessary to describe one thing that we are *not*  
going to do.

DG: From my point of view there could be an inference drawn that  
everyone using the eContracts spec would be required to support a  
rendered, displayed contract.

Considering the delays inherent in modifying the document it might be  
better to address the need by dealing with the motion when accepting  
the document [later in the meeting].

JH: Thatís OK by me.

DG: Could you think about some clean language for us to consider when  
we decide on adoption of the document?

Dr. L: Iíll work on it.

JH: Next is 3.2.1 Addition of Emphasis handling

Rolly: If you are envisioning an emphasis element that could be used, I  
would rather see that called something other than emphasis. Emphasis  
implies formatting.

JH: Sure. I wasnít trying to name the tag...

Rolly: OK. What about representing lists?

Peter: The requirement that lists be represented is in there as a part  
of structures.

JH: The things in part 11 are the things we need to develop more detail  
on as we develop the clause model.

DG: At some point we will have to address the issue (especially for  
consumers and displayed contracts) that some parts of the contract need  
to be Ďconspicuousí. Do people think that is a requirement that belongs  
in this document, or should it be dealt with elsewhere? It can be  
addressed in a presentation-like way.

Peter: I was trying, in section 11, to provide an indicative list  
rather than an exhaustive one. Jason?

JH: Generally speaking Iíd like to capture things we have thought of so  
that they are not forgotten. As you point out, it can be represented  
structurally or in terms of non-structural markup.

JH: 3.2, the motions... Are people comfortable accepting the  
requirements document?

Jim Keane: What about handling the quorum issue?

DG: We are the TC. And we will bring the formalities up to speed in the  
next call...

JK: I just donít know what basis we have to make a decision... what are  
we trying to achieve?

DG: We are trying to accept a set of requirements.

Rolly: If anyone is troubled by what is being considered then they  
should be on the call.

JH: Sergio and John Messing arenít on the call, but everyone else that  
seems to be involved is on the call.

DG: I agree that we have web-based tools, but this [the conference  
call] is a powerful forum. There are 13 people in the group.

Jim Keane: I am just a bit concerned by the informality and the not  
following the procedures of OAISS. That said, I am OK with moving  
forward.

DG: Fair enough. And we are dedicated to straightening out the  
administrative issues.

Dr. Leff: Here is some proposed wording: It should be convenient to use  
the clause model for applications where the XML is the contract and is  
used as an exchange between applications and is not intended to be  
displayed or represented in printable form.

DG:  Can we make that clearer?

Peter: Iím not clear as to what this means. Contracts are between  
people and ultimately people will be evaluating them.

Dr Leff: Two agents can have a contract, or an automated purchasing  
system. Neither party necessarily knows what the other party is looking  
at. The only thing that is common is the exchange of XML

Peter: The purchase order is a contract, yes, but we arenít marking up  
contracts yet. We are only marking up the human readable parts. There  
is a lot to a contract (as we have discussed) that we arenít marking up.

Dr. Leff: But the clause model that we develop for the human readable  
part should not inconvenience the instances when people want to do  
other things with the schema.
The upshot is that some things may be zeroed out. [Some display  
parameters may be set to zero.]

Peter: What you want is that if your ĎXML onlyí contract contains terms  
that are human readable then you want to be sure that the XML does not  
cause problems with the automated system.

DG: I like the way peter phrased it. Paraphrasing:
Assure that the structural markup does not inhibit the use of the  
standard for uses in non-human readable applications.

JH: Iím not sure how the change we are proposing will affect things.

DG: Iím not sure either, but as an automated contracting enthusiast I  
do want to make sure that we donít inhibit that type of activity.

Peter: We are taking up a narrow scope currently. By suggesting an XML  
only transaction, that may be out of the scope of what we are trying to  
do. I am a bit concerned that we impose a machine readable model on  
something that is human readable.

Dr. Leff: I agree. That would be a mistake. But in the process of  
making a contract human readable we donít want to inconvenience the  
users/development of pure machine applications.

Rolly: But why is it difficult to say that we donít want to inhibit  
machine-to-machine transactions?

Peter: I donít have a problem with it. But I want to make sure that I  
understand it.

Dr. Leff: If one of these terms represents a unit of obligation, then  
it shouldnít be nested in a bunch of levels...

Jason: What we are doing here is marking up the paragraphs that appear  
on the page. When you start to talk about units of obligation then you  
are talking about the other thread, the non-structural mark-up...

Dr. Leff: There may be a Ďbody of contractí tag and then a series of  
statements.

Peter: The point is that we are marking up the structure and it is not  
intended to be interpreted in any semantic sense.

DG: It seems that we are in agreement... Letís go with the original  
motion as described in the agenda with the context of the discussion as  
represented in the minutes.

DG moved to accept the proposal

Jason seconded

John McClure: I move to table this until we have a better understanding  
of the clause model issues.

DG: is there a second?

J McClure: Can we have discussion?

DG: It isnít a live motion until there is a secondÖ

[waiting... but no second]

DG: I am in sympathy with your point but I feel pretty confident that  
we are in a good position to address it at this point, even in advance  
of completing discussion of all of the scenarios.

DG: I didnít second your motion not because I thought it was  
unreasonable, but because I thought it wasnít necessary.

John McClure: The first item that I think deserves discussion is the  
expansion of the scope of the TC beyond what was described in the  
charter. I think that this is an inappropriate vehicle to amend the  
charter.

Peter: This point was addressed in the last conference. There was an  
implicit agreement last time and this was being formalized this time.

John McClure: I wasnít aware that we agreed to change the charter last  
time

Peter: I disagree that we are changing the charter.

DG: The charter gives us considerable latitude to change the  
requirements.

John McClure: Perhaps, but we are tasked with representing contracts,  
not every conceivable type of document that could be generated.

Peter: The argument is that there is no commercial basis for having a  
DTD that is contracts only. Our basic proposition is that you need a  
more general purpose DTD in order to gain adoption.  Thatís whatís  
driving this. If we go down the route [of contracts only] we are  
committing suicide. We are not in violation of the charter, we are  
simply doing what needs to be done in order to have a successful  
standard.

+++ John McClure: Item#2, this is a requirements document, and yet it  
does
not allow for the markup of the "document" that is legally-recognized AS
a contract. The reality is that this is markup for  some other document,
for some other document than the actual and true, legal contract. So
therefore I disagree with the liberal use of "contract document" in the
specification we're voting on.

My suggestion as to how to address that particular issue is to qualify  
at a minimum that, wherever it states that is the requirement for a  
contract document, to change it to say that this is a requirement for  
the Ďpre-contract documentí

As for making a standard that is useful: Understand that there are XML  
dialects that are used by browsers that are used to make presentations.  
(HTML etcÖ) It is that XML that needs to be annotated to represent the  
semantics. If we are trying to represent semantics then the issue  
becomes how to create a markup that is coordinated with HTML standards  
rather than developing our own.

JH: Arenít you talking about the non-structural stuff?

DG: In the interests of time, if you could rattle down what other  
issues you might have... It would be good if you could put the things  
forward that you might have to say...

John McClure: Happy to oblige.  There is no definition of terms. I have  
no idea what is meant by many of the terms. I really do raise a flag  
about the proper way to write a requirements doc. It should not include  
rhetorical questions.  It should be definitive (in the sense of  
defining). Iím concerned with the process. I thought that no XML was to  
be generated yet...

*** Scope issue, the way it is written, the definition of process it  
outlines, and (most troubling) that it doesnít address the most key  
issue Ė the contract (that it is a presentation artifact) and the XML  
representation.

Peter: My basic point is that John is seeking to revisit the previous  
discussion of the TC. Also, there was an invitation to submit  
amendments and it is unfortunate that he didnít do so. Iím not sure  
that it is productive to engage in the debate.

DG: Does anyone else have comments?

Dr. Leff: I think that the coordination with other groups is implicit  
in some of these concerns. If we are trying to interface with things  
like open office and court documents and so on, then we should be  
getting involved with those groups.

DG: Can you see to it that this becomes an agenda item?

Dr Leff: yes.

John McClure: The vote last time was to close general discussion. I am  
not trying to open general discussion.

DG: I want to be very clear that everything that you have brought up  
*is* in order. One of the things you said in particular I feel quite  
strongly about. I find it somewhat troubling that we havenít gone  
through all of the requirements.  However, given that this is  
structural and not semantic, I am not raising the issue formally.

Although we have worked diligently we still donít have a full  
understanding of the requirements Ė so I am keeping an open mind about  
it. Having said that, I am still in favor of the document.

Dr. Leff: I agree

Rolly: I agree. By approving the motion I donít think I am giving up  
the right to come back and revise things.

Peter: I agree, but I think it will help us if we have something that  
we can work around.

Dr. Leff: This can become our statement of work. This will be Useful  
when working with other groups.
*** [Note: Dr. Leff mentioned that the Electronic Court Filing  
Technical Committee is using the "Statement of Work" as the first step  
in the process of developing a work product.  Mr. Winters prepared a  
detailed document describing the process, adopted by that Technical  
Committee. It is Dr. Leff's understanding that this may be suggested as  
a model for adoption by
other Legal XML Member Section Technical Committees. Folks should let  
Dr. Leff know if they want him to follow up with Mr. Winters for more  
details.]


John McClure: The fact remains that we are going back and undoing the  
Ďpreliminary agreementí or whatever the term, about hierarchical versus  
recursive models. There was a lot of work that went into that. Now we  
have been presented with a set of requirements to examine (that donít  
have the quality or quantity of backup materials of the recursive  
model). And now, without much discussion from the group about the flaws  
in the hierarchical model, it is being tossed aside.  And we donít know  
where it is going because there are no examples.

JH: I donít think that this was tossed aside.  We learned a lot through  
that process.

DG: Are there any other comments on the motion?

[none]

All in favor of the motion that:
The TC accept the clause model requirements document;

9 in favor, 1 opposed.

John McClure: Point of order. This looks like the process that was  
included in the document that was just assented to.

DG: Does anybody object to this process?

Dr. Leff: I donít object to the process, but I wonder how it integrates  
with the previous discussion.

JH: Could you post anything you think is appropriate to the list?

Dr. Leff: Sure
*** [Note: This was done later as  
http://lists.oasis-open.org/archives/legalxml-econtracts/200306/ 
msg00021.html]CD_Burn

DG: Any other comments?

DG: I move to accept 3.2.2

JH: Seconded.

Approved by all, with 1 abstention.

DG: Other new business?
[none]

DG: It is my expectation that the next few meetings will be less  
procedural and more addressing the substance.

If everyone could please review Rollyís scenario in advance of the next  
call thatís be great.

Dr. Leff: There has been additional slippage. What should we do about  
the forthcoming schedule?

DG: For the purposes of saving peopleís time, there is consensus of  
discussing the ORD scenario on the next call. Weíll sort out the rest  
offline.

Meeting adjourned



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