Draft minutes, May 11, 2004

[Dave Marvit <dmarvit@pacbell.net>]

Folks,

here are the draft minutes of our last meeting. Some parts of the 
conversation moved pretty quickly. If I missed anything, or 
misrepresented anything, please let me know.

Thanks, and I'll see y'all Tuesday, May 25th.

-Dave Marvit
Fujitsu Labs of America
Fujitsu

--------------------------------------
LegalXML eContracts
Draft Minutes May 11, 2004

In attendance:
John McClure
Dan Greenwood
Dave Marvit
Dr. Leff
Zoran Milosevic
Peter Meyer


[Dan reviews the current status of the group.]

John McClure: I offered to review the presentation that Jason gave in 
New Orleans. This would give us the opportunity to see how we were 
represented in New Orleans.

[Discussion of where we stand WRT the requirements doc. Are we working 
on an evidentiary contract doc?]

Dan: Is there anything else in the Structural group that you are 
seeking more input on? Or is this intended to be a report?

John:  Input is always welcome, although I haven't been tasked with 
getting feedback on any specific issues.

Dan:  Some of the issues as to what is in scope could be addressed by 
seeing

John: The main issue that we are grappling with right now is when we 
take the name of a party (that is in the vast majority of the time 
named in the contract) -- should that be semantic or structural? It may 
need specific formatting. So, do we have a party name element or do we 
have a span element.

Now, there is no doubt that we all want to be able to extract the names 
of the parties. So, the question we are struggling with is if the name 
of the party or parties is to be extracted form the content, the 
language, or if we are pulling it from some other source - say from a 
file that contains the semantic description of the contract.

Dr. Leff: I was not left with the impression that this was the clear 
consensus. I had neither a negative nor a positive impression of this.

John: I think all of us feel that it is important to extract party 
names and other info from the document.

If the part name is only located in the content of the document then 
that caters to those who are using XML editors. If we have the parties 
identified out of line with respect to the contract, then the person 
using the XML editor would need to create 2 files, or create 1 file 
with 2 parts.

Dr. Leff: This has been an issue since 2000 in other groups as well. 
This is a big issue for court documents and several other groups.

Dave: Can we ask the meta-question as to how to arrive at the right 
answer?

Dr. Leff: Perhaps by implementing both solutions...?

John: You mentioned that your students have had a discussion about this 
problem.

Dr. Leff: Well, we submitted a solution to the court filing TC and they 
wanted something different. The solution we were involved with was to 
include tags that delineated party names embedded in text. The TC said, 
“Can you show us something that looks more like XML.”

John: Jason had a slide that showed how to represent a warrant that 
included XFORMS. Slides 28 and 30 are worth checking out.

Dr. Leff: There are a lot of very reasonable technical solutions. The 
question is which would be optimal for implementers and users of the 
software.

[Reviewing slide 30]
John: What Jason has shown here is the use of XFORMS with XHTML 2.0

The issue surrounding this use of XFORMS is that it requires an XFORMS 
processor.

Peter: I don't think that there is a relationship between this arrest 
warrant example and the markup from the contract.

Dr. Leff: I think that it does show us how we could have the 
information in the contract in a extractable way and still have it look 
something like a contract.

Peter: Absolutely, but we aren't at that point yet. There are lots of 
pieces of information in a contract

The issue of party names... The issue is weather the author can use 
relatively simple markup, or weather they will need some more advanced 
technology. We believe that you should NOT need to impose something 
like this on the base markup. Then, if you want to step up and add 
complexity, that's OK.

John is more inclined to see the additional level of complexity applied 
to everyone.

Dr. Leff: Can we get both?

Peter: I suspect that the answer is “yes”. But I am not technically 
savvy enough to have a specific answer. So I think we need to see what 
people need to do and see if we can find a way to meet people's needs. 
I think it is premature to say we have to do it this way or that way. 
For now I am just resisting the imposition of this into the structural 
model. We need to think about it more.

Zoran: To what extent ... What is the status of the structural markup? 
If we put aside this issue, what is the status of the structural markup?

Peter: We have made a lot of progress. There are still a lot of issues 
to resolve. There are differences...

If we set aside the issue of the parties, then we have one issue to 
resolve with the high level structure of the contract. I think we have 
basically solved that. We will stick with the model that Jason put 
forward in New Orleans. The major remaining ones are numbering of 
sections and the signature block. Then we would move on to a group of 
points covering cross references, defined terms, and some markup of the 
party names. If we can get to that point (where we can deal with cross 
references, defined terms etc...) then we have a workable model. You 
could actually go use it.

Zoran: Cross references within a contract or between a contract and 
other documents?

Peter: Well, of course we mean within a contract. But ultimately we 
would like to support references between contracts. That is an issue we 
will have to look at and take advice from the TC as a whole. We will 
probably be handling internal cross-references first.

It is moving frustratingly slowly. It would be nice if we didn't have 
the differences of views that we have, but it is probably for the best 
because it reflects the world where there are lots of people who have 
different views. The result will be better for it.

Zoran: Are you trying to have a solution that is independent of XHTML 
2, and then map it over?

Peter: No, we are doing this in the context of XHTML 2. The difficult 
bit is figuring out what additional elements need to be added. So far 
we have only added 2, the number element and the instrument element. 
This is a discussion that is going on right now, the discussion of 
adding additional elements. It IS likely that when we add signature 
blocks, we will need to add additional elements.

Dan: What is the status of the struct element?

Peter: If we are going to have an element performing that function, 
then we would probably use div for that purpose. So struct is probably 
dead.

Dan: And John, did you have an opinion on that:

John: I thought that Div was a good choice because it reflected a 
division in the document. Also, we had no function allocated to div so 
it was available.

Dan: Div does or does not appear in XHTML 2?

Peter: Does.

Dr Leff: What about section?

John: Section is really for clauses. Sections contain numbers. A div 
does not require a number.

We have not resolved the use of divs within divs.

Dan: Could you explain what divs within divs should be required if...

John: The notion of a div is to identify parts of a document. A common 
part is another attachment.

Issue #1, is the cover page part of the instrument?

Dave: What is an instrument?

Dan: I deem it as the overall contract document.

Peter: I think that in legal parlance, it is a document that does 
something. There is no collective notion about it. It is in the sense 
of 'instrumental'.

Dan: It is very unusual for there to be more than one operative 
document in an instrument.

Peter: I don't see how we can prevent div from being used inside div.  
The conception of it up until now has been that it can be recursive. 
And that is a problem.

Dan: Nobody is thinking about nesting instruments...?

Peter: No, it is merely that there is a problem having div be a 
competitor to section.

John: There is not too much question that we will be able to have 
instruments with divs.  There are all kinds of cases.

Dan: Could we do that through inter-instrument cross-referencing?

John: We could, but that violates the XML ideal of encapsulating.

So.. is the cover page part of the instrument? I maintain that it is 
because it should be encapsulated inside the instrument so that it 
could be referenced as a single unit.

Dan: So, when do you expect to be finished?

Peter: Another couple of months...?

Dr. Leff: Could you say that we are doing the second 95%?

Dan: Do you think it would be most useful for the TC to sequester for a 
while until you are further along? I am a little reluctant to push on 
other issues until we have more done on structural.

Peter: A fair point. I don't think we are ready to deal with semantics 
yet. I think that we could continue work on requirements. If we have 
structural, then people will be able to actually use it.

We have a lot of work ahead of us to work out the semantic issues.

Dan: When we get structural, I'd like us to consider battle testing it 
and then releasing it as a 1.0 structural, then it would be followed by 
a 1.0 structural, then a 1.0 envelope that don't need to come out at 
the same time.

Zoran: I think that having requirements will be the most important 
thing we have to do at this point. I think we need to set a deadline.

Peter: I agree.

Zoran: I'd like to push on the requirements doc and get everyone to 
have full agreement as to what the requirements should be.

Peter: I agree that the requirements are fundamental. That’s the 
problem that is bedeviling us. At the heart of the questions John is 
bringing up, about cover pages and so on, is our requirements. It is 
not a technical issue at all. It is a fundamental requirements issue.

John: I am pushing for a very simple use case where someone gets an 
offer and they print it out, sign it, and send it back in snail mail. 
It is a simple use case.

Peter: It says nothing about what needs to be in the markup.

John: It says that all of the content that people perceive in the 
contract needs to be represented.

Dan: There has been a point of consensus that the most important thing 
is for the group to produce a requirements doc. Rolly has been doing an 
outstanding job on this. Still, I am sure that having Zoran involved 
would only be a good thing.

Is there consensus that we should take up Zoran on his offer to help 
out Rolly and get the requirements doc together?

Zoran: My action point is to contact Rolly and see if we have 
outstanding issues.

Dave: What methodology should we use to actually address the issues 
that are causing us problems? They don't seem to exist at the same 
level as what we have been calling requirements.

Peter: Yes, that's precisely the point. The use analysis we did at the 
face-to-face in Sydney was useful.

Zoran: I will look forward to following up on this.

Dan We have used over an hour. Are people prepared to wrap...

[Consensus on wrapping up the meeting.  Meeting adjourned.]