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 - v1


Folks,

Below is my attempt to represent another meeting with rapid and heated 
discussion. I am confident that I have not done justice to all of the 
opinions expressed. Please let me know what I've missed and I'll revise 
the minutes as quickly as possible.

Thanks,

Dave Marvit
Fujitsu labs of America
dave@marvit.org

--------
Draft Minutes (Version 1)
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 a... The reality is that this is markup for 
some other document, for some other document than the contract document.

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

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

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]