Draft minutes April 13 conference call

[Dave Marvit <dmarvit@pacbell.net>]

Folks,

Sorry these are going out so belatedly.  Please let me know if you have 
any changes.

Thanks,

_Dave

Dave Marvit
Fujitsu Labs of America
Fujitsu

----------------------------------------
Draft Minutes
LegalXML eContracts TC
April 13, 2004

In attendance:
Jason
Rolly
Charles
Bill
Dr. Leff
Dave
Peter
Zoran
John McClure

The meeting began with Jason giving an update of the work of the 
structural subcommittee.
Jason explained that, in spite of good progress, much remains to do. 
Signature blocks, numbering and tables remain. After that "We should be 
able to mark up a broad range of contracts."

Jason added that we have a number of sample signature block s that we 
should be able to represent. (He adds that "Pretty much all of the 
issues are in the document that was circulated on the list."

Following numbering we have to address tables and styles. Next comes 
page breaks, headers and footers. We may want to come back to the TC to 
get some guidance on some of these.

Peter: Basically we need to look at use cases to resolve these issues.

Rolly offers to review the requirements draft point by point

[Some discussion about Jason's comment that the charter includes 
representing contract terms in addition to representing contract 
documents. Should that be soemthing that we worry about now?]

Peter: I believe that the intent was t make a distinction between 
contract documets and the ability to look inside the contrcat to look 
at the contract terms.

Rolly: As I recall that was put in the charter to address the issue of 
semantic markup

Peter; Well, it could have been, but I think it was about making sure 
that we looked at the content of the documemnt, rather than simply 
putting a wrapper around the document.

[The group concluded that, for all of the scenarios that were 
reasonable, our current work addressed the issues of concern and hence 
no revision to the carter was in order.

Rolly: Any objection to that?

[none]

There was then some discussion about the purpose of Rolly's 
requirements document. It was more for the purpose of deciding what is 
in or out than for eliminating technical discussion down the line.

Dr. Leff: I think we are talking about weather or not we will state our 
deliverables.

Peter: Well, I guess that we could state our deliverables -- broadly. 
I' d like  to be able to say that people should be able to do these 
certain things. [...] I still don't know what the group is tryng to 
achieve

Rolly: Should this be a seperate doc, or this one...?

Dave: I'd prefer to do it in a seperate doc. We get a finished work 
product.

Rolly: I sense some sentiment to keep that ssue in the forefront of the 
group, but to keep the resolution in a different context from this 
document. Is that correct?

Jason: I guess that philosophically the doc shouldn't just be trying to 
recite the requirements that different people have put forward. Rather 
it should reflect robust dscussion at a high level of what we are 
trying to achieve, and also include dicussion at the nuts and bolts 
level. I think there should be some rough and tumble over getting this 
documents right.

Rolly: Which requirements would you throw out of the current draft?  
All of them?

Jason: I gueess that one of the areas of painful discussion that we 
have had in the past is getting straight this issue of the evidentiary 
contrcat document and that this is not what the standard is about. That 
satement is not in here and it probably should be.

Peter: I agree with that. It is not that any of these [requirements] 
should not be in there. This is a good pulling together of the points 
in the scenario.

Rolly: I don't take it as criticism. I was simply pushing for that 
rough and tumble...

Peter: From my point we need to reslve who this is really being 
directed to. How will they actually use it. That's not in here. I don't 
think we can address the requireenmnts untill we address the users.

Rolly: There is a section 3.1 on user classes and characteristics -- I 
found your initial crack at that very helpful.

Peter: Yes, that's where we need to start. we need to put ourselves in 
the shoes of the people who will be using this. The scenarios cover 
some of this but they don't really address what problems we are trying 
to solve from a business point of view. Should it necessarily be XML, 
and should it necessarily be standardized?

Rolly: Let me press you, who should it be?

Peter: Organizations who create lots of contracts -- human to human 
contracts, then you can talk about high volume standard contracts, like 
in banks and insurance companies and so on... we can look at what 
problems they have in document production, what problems do they have 
when they negotiate them, and when they try to transmit these contracts.

You then have online click-through contracts. You have corporations 
that want to extract information for contract management purposes.  
Dispute resolution (which is still experimental) and commodity 
contracts that are highly standardized and parameterized for automated 
negotiation.

We have to answer in each case why will using XML in markup help them. 
And if it does, then why should it be implemented as a standard. Unless 
we go through that process we can't develop our requirements.

Roly: Comments?

Dave: Some of that is in the scenarios, but at a different level of 
abstraction.

Peter: That is right.

Rolly: It sounds like if we want this in this document then we need to 
describe why XML is a step forward and not a step sideways. So.. which 
way is the wind bowing...?

Bill (?): It sounds like it could add several months to the publication 
date of the document.

Peter: Yes, it would, but if we don't solve this problem we will be 
working with a shaky foundation. We will just be repeating the mistakes 
of the past if we let this go forward without addressing these issues.

Jason: The problem is how do we actually focus on the things that 
matter? There has been plenty of debate between John McClure and I, but 
if you read our scenarios then it is not apparent on the face of the 
scenarios that there is anything to debate and discuss. So I'm just 
wondering if writing down the use cases will be the panacea we hope it 
will be.

We kind of need to identify and nail the points of debate as they come 
up. If we are going to write down these use cases we need to find a way 
to make sure that they do nail...

Peter: That's the purpose of the exercise

Jason: But why didn't the scenarios do this already.

Peter: We have all made assumptions about what we wanted. These may 
have included a misunderstanding of what should be standardized and 
even what a standard should be.

Rolly: Let me inject that section 3.3 of the current draft -- entitled 
'typical problems to be addressed'. It contains what I tried to extract

Peter: And I think that was a good start. And as a starting point it 
was fine. I felt that those were a little bit general. The requirements 
were a little bit disconnected from these. I thought that they were a 
bit too general to be useful.

Rolly: Some of this touches on Jason’s second comment towards the end 
of section 1. Should we be considering what should be in subsequent 
versions? Some of this goes to the point Jason was raising by that 
comment.

Jason: Yes. Is this document a collection and abstraction of the 
requirements from the scenarios, or is it a discussion of the 
requirements that are important now, and a discussion of what can be 
left for later. I'd prefer to do that.

Peter; I'd agree with that. It would help us focus our later work.

John McClure: That kind of document, a roadmap, is often included in a 
separate doc.

Peter: It can be done either way.

John McClure: Sure

Peter: I think that when you have everyone at the table you can do it 
all in the same doc.

John McClure: What is the resolution to the issue about having the 
scenarios linked into the document...

Rolly: Are you concerned about the scenarios being made public?

John: I'm concerned that hey are not in a single format.

Rollly; I am in the process of putting them all into a single document. 
I would consider putting it all into the one doc and then eliminating 
the external links. I put those links in there for our purposes for 
traceability between requirements and scenarios.

John McClure; I am wondering if putting the scenarios in a common 
format would help with the tasks that Jason and Peter are putting 
forward.

Jason: If we do our job properly then a casual reader should not need 
to refer back to the individual scenarios. Peter...?

Peter: I think there should be references to the scenarios, but I don't 
think they should be annexed. I think that the doc should stand on its 
own. You can't just extract the requirements from the scenarios and say 
here are our requirements. They haven't addressed (for example) why XML 
and why a standard, for a variety of users and a variety of needs.

John: Well, I'm sure that this statement comes as a surprise to the 
scenario authors.

Peter: I put myself in that category too. We have had disagreements 
that haven't been resolved and that is because they are based upon how 
we think the world should be rather than how it is -- based upon users' 
needs.

The scenarios were great. It was a great process. But there is a whole 
lot of analysis that has to be done to figure out what the requirements 
are. Just pinning the scenarios together won't do it.

John McClure. I agree that there is a lot of analysis to be done, but I 
don't think that these will invalidate requirements. It can be used for 
solution strategy and so on...

Peter: I disagree with that. None of us can say 'I put it forward so it 
should be a requirement.' It may not fit in with our strategy, or it 
may not fit in for a while.

Rolly: I know it is getting late and people are going to have to sign 
off shortly. Let’s get together next time and discuss if the level of 
analysis that Peter and Jason think we should be doing should be 
included in this doc... and if not, then where it should be done. It 
seems that there is some consensus that it would be a good thing to do.

Also, we can look at the issue that Jason brought up about what should 
be done in the first and later versions.

--Next meeting is scheduled for April 27th..