August 11, 2004 Draft minutes

[Dave Marvit <dmarvit@pacbell.net>]

Folks,

Here are the draft minutes for the Aug 11th conference call.

_Dave
---------------------------------------
LegalXML eContracts Draft minutes
August 11, 2004 conference call

In attendance:
Zoran Milosevic
Dr. Leff
Rolly Chambers
Dave Marvit
Dr. Colyen Sue from the W3C (As a guest of Zoran's)
Peter Meyer
Dan Greenwood
John McClure
Jason Harrop

Zoran: Colyen is a DSTC staffer and our W3C rep. As you know, DSTC is 
the Australian W3C representative. I thought he might have some useful 
insights and invited him to join us today.

Dan: Great. Do you need any BG info, or are you OK?

Colyn: I'm OK, thanks.

Dan: Good. Where we left off, people were going to distil down their 
use cases into the template that Peter has prepared. Is it fair to say 
that we are looking for people to provide feedback on the template? 
Peter?

Peter: Yes, I submitted a draft and a slightly overly long use case. We 
do need feedback on the template, and feedback from anyone who has time 
to read the use case as well.

Dan: I think that's a good first agenda item, to put that template to 
rest. Then to set a deadline for those who want their use cases to be 
included in the  face-to-face.

Zoran: I was hoping that we could address the structural issues because 
we have Colyn here. He needs to leave in 30-35 mins.

Dan: Good

Structural..., there are some open issues. There is a report and a 
minority report in the offing. Some of those open issues blur into the 
scope of the requirements and spec itself.

Would one of you be willing to frame the issues for our guest...?

John McClure: I'm not sure exactly what topic it would be best to have 
our guest focus on...

Dan: Well, please give us a quick walk through of the issues and that 
will form the basis of the discussion. Then if we can try to make this 
actionable at the face-to-face...?

Jason: Can I give a brief intro?

Dan: Please

Jason: We went to the New-Orleans face-to-face with what we thought was 
a reasonable clear appearance for everything, clauses and lower down. 
We were going to use 'section' - the same element that occurs in 
XHTML2. We were all clear on that. We also had a discussion abut the 
high level structure.

In New Orleans there was a high-level container model of the structure. 
We all understood all of that  (parties and so on). We were calling it 
'struct', just for the purposes of having something to talk about. We 
thought we could put an attribute on top of that.

We thought we needed to finalize the attributes and address some other 
things like signatures.

In New Orleans when I went to mark up the date and the parties I 
realized that there were three ways I could mark them up. I picked one 
- use a 'P' for paragraph and have each of the parties inside it.

Peter chose to mark it up with a bunch of 'P's and John chose a single 
P with a bunch of line breaks.

We decided that we needed a way to make it simpler for people to make 
up the date and parties and background. We need to make it easy for 
people to do this in a single way. Peter and I thought we needed a way 
to do this in an unambiguous way. This is where the subcommittee ran 
into difficulties - having differences of opinion that the subcommittee 
couldn't compromise.

The preliminary report was designed to have elements that a lawyer in 
the US or Australia can understand. The background element for a 
background or recital, operative element for operative clauses etc.

In any case, our approach was to use elements that mapped closely to 
real world elements. John's approach was slightly different.

I should probably pass the floor to John here.

John: Basically I wrote the minority report for a number of reasons. I 
thought that for the TC as a whole it needed to be in a less 'working 
notes' format -- something that we ought to be able to publish. I did 
it using the markup that I am proposing we use.

The markup uses the original understanding of using XHTML2 and adapts 
it to our requirements as we understood them and sticks to at least the 
spirit of XHTML2 as the implementing name space.

The section element was an easy one.  I incorporated three of the 
elements with different elements suggested by Rolly that Jason agreed 
to. There is some consensus on having recital, preamble, or recital, 
body, and signature.  This is a legal signature.

In XHTML2 we have to precede each element with a prefix. I'd like 
"legal:"

I felt this is appropriate. Rolly and Jason seem to agree. The 
discussion seems to be about elements called extra or extras for the 
divisions of the document. If one looks at the XHTML2 definition of the 
DIV element, it says  that DIV is used for those extra elements outside 
of the ... the notion is the idea ... inside of an 'extras' element 
would be one or more extras (as proposed by Jason et al). But DIV is 
designed to be recursive.

So, the DIV element seems to be a more natural candidate because it 
matches the intention that formed our subcommittee in the first place.

This comes from a document that was sent to the subcommittee that 
contained 12 points. This is the high level. Using DIV to represent the 
high level -- it just seems that the first easy issue that we could 
dispose of is if the TC feels we should be establishing 'extra' and 
'extras' elements instead of DIV. To date, neither Jason or Peter have 
established the use of a DIV element.

Jason: If I could respond quickly - I think that if we focus on the 
preliminary report... the issues we have discussed since we released 
that, there are 3 issues.
First, the extras element or DIV. Second is, of course, the date area 
and the PARTIES element we proposed for Anglo-Australian contracts. I 
think we need to justify why those are there. The third is the 
namespace issue. Our report didn't focus on that but people have since 
proposed that all of our elements should be in the legal namespace.

We are going to use a model ..

John: What exactly is that question? We only have time for one issue...

Peter: We can't separate them out like that. It is misleading.

John: What is the actionable question?

Peter: I don't think John has fully stated all of the issues. We want 
the part of the contract that has the dates and the parties to be 
considered for Anglo-Australian contracts. The namespace is the other 
part. This bears on our level of conformity to XHTML2. It is not a 
given that we have to use DIV. It is massively over used and abused.

If we add those to the list then we have a range of issues. Ultimately 
it gets back to requirements.

Dan: Great. Thanks. I think we can do the logistics part in about 15 
mins which would leave us about 10 or 15 to discuss these issues.  Can 
I toss it open to the group for feedback.

Rolly: I provided some feedback offline. Everyone has been flexible 
about element names. I don't think that will be a make or break issue 
for anybody.

The question of whether there are traditions in the US and different 
ones in the Anglo-Australian cultures I don't really see. I think that 
the priority is to be consistent. The US tradition for the contracts 
that I have seen would include date and party names in the opening. I 
think that the proposal that has been submitted could satisfy people in 
either tradition. I don't think that there is an issue that needs to be 
addressed beyond making a guess.

Jason: You are saying that 'P' is OK for North American contracts?

Rolly: If we chose to do that. I am also saying that date and party 
area is also OK for US contracts. Rather that offer a choice I'd like 
us to pick one or the other.

Jason: The 'P' element is clearly the best way to represent US 
contracts. I just picked one up off of the floor and it has a bunch of 
stuff in that first paragraph that is not parties and date.  If you 
tried to use the Anglo Australian.. you could say that the first line 
is the date stuff and the next couple of lines is the party stuff. But 
where does the rest fit in?

In Anglo-Australian contracts the date area and the parties model is a 
far superior model. You end up where you can fit the Anglo contracts in 
to the American P or the reverse, but it is an uncomfortable fit. In 
the face of that uncomfortable fit why don't we have the elements that 
fit both, naturally?

John: A lot of this goes back to the issues that we are trying to deal 
with professionally and intellectually. If we use the XHTML2 approach, 
they use a property name and an element. That said, the scenario that 
Jason and Peter are professionally very much involved with -- that 
works best if there is an element name that is date/time (line) that is 
a container for some set of text strings.

I think that, if we are talking about jurisdictional differences, there 
is no reason that we can't craft our elements and our schema that can 
be build upon jurisdictional versions. Then we'd have an element called 
date/time that would operate the way we want it to operate. By adopting 
the XHTML2 architecture, it does not preclude us adopting a namespace 
that includes jurisdictional elements.

Jason: These elements we have proposed, date area and parties - it is 
my claim that these are no more semantic that other (...) elements. 
They are structural. Contention #1 is that they are structural elements 
pure and simple.
Contention number2 is that the element name is far superior for my 
scenarios and Peter's to a class attribute. The reason that they are 
far superior is that it is not possible to contextually constrain the 
value of the class attribute. If you say that we have 50 different 
possible values for the class elements, then you want the user to pick 
from a drop down, it is not possible to have the user chose from the 
ones that might be contextually relevant. So, the element approach is 
much better.

John: But what is your reaction to the approach that I have described - 
having jurisdictional elements?

Jason: Not needed.

John: You could build ..

Jason: I agree that we could have an extension mechanism that could 
handle all kinds of things...

John: I am not talking about an extension mechanism [like court 
filing?] What is wrong with the extension mechanism that is included 
inn the languages themselves?

Jason: The elements should not be relegated to some extensions.

John: Why?

Jason: Because these elements should not be relegated to being second 
class citizens.

John: But standards are all about building upon pre-existing work...

Dan: Ok Guys.

John: I would like a vote-able proposition put on the agenda...

Dan: I don't think we are ready to vote on anything today.

John: I am not saying today. It is not on the agenda. But I don't want 
to have another discussion that is not going on anywhere.

Dan: My suggestion was to get feedback form the group. I was hoping 
that we could use the F2F as a deadline of sorts to refine the 
requirements and to nail down the structural. The intent of airing the 
issues today is to air the issues.

Jason: Should the next step be for me and John to shut up?

Dan: Yes, but I want to have 2 minutes of discussion so we will know 
where we will be on the use cases. I think all we need is a deadline to 
have the use cases submitted so that we will have them ready for 
discussion at the meeting.

Dan: I  personally reviewed [Peter's framework]. I thought it was a 
little long, but I can get my scenarios into that form. When would we 
need to get them into that form.

Peter: We'd like 2 weeks to review them, so by the 25th.

Dan: [Discussion] How abut Sep 1 as a deadline for people to submit the 
use cases we will consider.

[consensus]

[travel and logistics discussion]

Dr: Leff: There are a couple of things we can do. For paragraphs, DIVs 
etc., we can do what other groups have done. The LegalXML namespace  
can inherit from the XHTML2

I think it is critical that we can pull out party name and address from 
the contract. We can do that by adding an element (address or 
something) or you can have a reference element and then have references 
to that from within the paragraph. Then you have everything pointing 
back.

Zoran: I personally like this approach a lot -- with the references.

Dr. Leff: Yes, the text looks like text for the lawyers. The 'actor' 
element of court filing 1.1 (?) is a good example.

Jason: Do you agree that what you are talking about is structural?

Dr. Leff: Yes, but we have to be sure we can pull out the semantic data.

Peter: What Dr. Leff says is fine. One of those options should 
seriously be considered, but that is not structural markup. What we 
have put forward does not preclude any of that.

Dr. Leff: Someone reading the docs might think that it is precluded.

Peter: We haven't written the report on the recommendation because it 
hasn't been agreed to yet. I agree with you, but it is out of scope.

Rolly: That position really does point to what we mean by structural. 
All of these terms -- background, parties and so on, all have a 
semantic component. I wouldn't get too hung up on the distinction.

Peter: There is obviously an overlap between semantic and structural. 
When you talk about date and parties you obviously have a foot in each 
camp. But the goal is to do what we can on the structural.

Rolly: If you tell me as a US contract author to use a P tag and I want 
to have the info marked up , then if I want to extract the info 
(address...) then I'm going to be frustrated.

Peter: You will have additional semantic tags marking it up.

Dan: Speaking as a member [and not as a chair] the reason we decided to 
start with structure is because we though it was content neutral. In 
the end, if parties fits into structural... I am doubtful... I wouldn't 
be inclined to consider it to be structural.

Jason: What tag would you use?

Dan: I would use 2. If there was a structural DTD I'd use that to get 
it where I wanted and get the font and appearance. Then I'd use a 
semantic tag to indicate that it was a party.

Jason: That's what we are doing

Dan: Why is that structural?

Jason: Because the parties part is structural. You would have the 
inside marked up with semantic tag.

Roly: Why don't we just stick date area and parties into an area and 
call it an intro?

Dan: Or something with even less semantic value, like header?

Jason: Because you use multiple paragraphs. You wouldn't want headings 
inside the date area and the...

Dan: I have done perfectly good contracts with HTML, with bold and 
paragraphs and so on.

Peter: But we don't want to address and constrain the formatting. We 
are trying to stay away from the markup. You are trying to...

Dan: But I still come back to the content neutral nature of it.

Peter: It seems that people think that because we are proposing areas 
called address and parties people think we are precluding semantic tags.

Dan: It seems to me that it is well into the semantic camp.

Peter: As Jason has been trying to explain, these parts of the document 
are significant. They are significant in terms of giving end-users the 
options as to what to put in, and it is important as to rendering it.

Dr. Leff: And we need to be able to take whatever information - use the 
software to pull out the names and pump it into the database.

Peter: I agree.

Dr. Leff: The it may be just a presentation issue, buy which I mean 
presenting the proposal.

Dan: I am hoping that this becomes a distinction without a difference. 
Whether it is classified as more semantic or more structural is 
ultimately not important. The requirements should help us.

Peter: You are right. Our approach has been to get what we need 
structurally. We need these containers.

Rolly; You need 2 'L' containers.

Peter; No, we need named containers. L containers are used throughout 
the doc.

Dan: "L"?

Rolly: It stands for 'line'. What I am hearing structurally is that the 
guys need 2 lines. They would rather call them date areas and parties.

Jason: We would actually need a paragraph with about 6 or 8 L elements 
in them and some would have to represent what in other parts of the 
documents would be headings. It is unnatural to use it in a way where 
you would be using ...

Dr. Leff: Couldn't we have a date area inheriting form a P element?

Peter: I don't see the point of that.

Jason: When you use that you end up with at least 3 different ways of 
using it.

Dr. Leff: Could you have a schema restriction?

Jason: We did solve it clearly with the solution we proposed.

Dan: We are at logical stopping point since we seem to be back where we 
started.

Peter: I think there are different perceptions of what we are trying to 
do, and of the importance of XHTML2.

Dan: Are you saying nail use cases and requirements as a precursor?

Peter: I would say that somewhat reluctantly.

John: I think it would be a good idea to have another discussion as Dan 
is suggesting. I would prefer if those discussions had a vote-able 
question that was the topic of that discussion and that we endeavor to 
vote on the topic. I am trying to be results oriented. The results of 
that vote will define the spirit and intent.

Dan: And the question of timing? Do you think we will be in a better 
position to make those decisions when the use cases have been developed?

John: I don't think so. Because this is about XHTML2 and that's not 
going to happen.

Dan: Jason?

Jason: I don't think another discussion 'OK, your hour is up' is going 
to help. I think John's suggestion is a good one, but I think Peter's 
idea about understanding XHTML2 and out relationship to it, that would 
be a very useful starting point for making decisions about date areas 
and parties and extras and name space issues. I'd suggest having a 
discussion about X2 and then return to the discussion.

Dan: The TC has decided to use XHTML2 to the extent practicable. And 
the W3C has a new version out that the TC hasn't looked at.

Jason: We all agree that we are basing  this on XHTML2. but how closely 
do we need to follow it? Even in the areas that we have agreed on we do 
need to look at this.

Peter: I agree

John: I think a good question to put on the agenda is to question our 
previous commitment to XHTML2.

Dan: I think it is something that the committee should do to be 
diligent. Can we get a walkthrough of the new version of XHTML2 and 
track it to the structural

Peter: The issue is how much do we care abot XHTML2?  That's the issue.

Dan: Any objection to having that discussion?

[none]

Zoran: It would be good to have the next week, if John has time.

Dan: Are people OK with the 17th?

John: Are people still interested in having a RDF subcommittee? 
Establishing a separate subcommittee to develop the data-model defining 
the semantics of the standard.

Peter: I think this is jumping the gun to do that in advance of the 
requirements. We did that once with the structural.

Zoran: I agree. Let's not worry about standards yet. We need the 
requirements.

John: I want it [requirements] named in terms of the technology. Its 
job would be to make a technology recommendation.

Dr. Leff: We have a resources subcommittee. It has been on the web site 
for some time. It includes technological and non-technological 
resources. We need to find out what the options are. The choice may 
well be aesthetic.

Peter: Or maybe we don't make a choice at all. But at this point you 
don't know what we are trying to achieve.

Zoran: We need to put all of our resources towards finishing a 
requirements doc.

Dan: John, I think what you are saying makes a hell of a lot of sense. 
But I would be loath to be on that committee before the use cases have 
been sorted out. It should write itself once the use cases are 
resolved. I'd suggest that we adhere to what you are saying. Perhaps 
after the use cases but before the F2F?

Peter: I think there is going to be some priorities being worked out at 
the F2F.

Dan: It seems that the time to discuss what we have harvested would be 
.. we have time for 2 meetings between the sep 1 deadline and our face 
to face. That would be a good time to start a free fire zone on the use 
cases. At least we wil know the landscape of use cases before the F2F. 
It would be a ripe time to have that discussion.

Peter: My apologies. I thought you were proposing the formation of a 
subcommittee before that time.

Rolly: Let me say that although I have some differences of view from 
Jason and Peter, they are not major. There is a lot there that shows a 
lot of good judgment on the part of the entire SC. John as well.

Zoran: I agree. I also want everyone to know that I am learning a lot 
from the discussion. I find this discussion really useful.

John: Well, it takes a lot of effort to be speaking from an informed 
position. That's why I would urge us to authorize us to form a 
subcommittee to deal with semantics. It takes a while to organize the 
processes and the information. We all have a basic set of 20 semantic 
items that we know we should be.. .We need to say ... The structural is 
there and there is a big hole and we all know it. I am surprised that 
people aren't more anxious to get going on it.

Dan: Do others want to form a committee now?

Rolly: I'd rather finish what we are chewing on.

Dan: Anyone want to start on this now? Dr. Leff, Zoran...?

Dan: Nobody wants to work on this now, but there are at least 3 of us 
who want to work on this once we are ready -- probably when the use 
cases are ready.

John; I certainly don't mind of the TC decides that a subcommittee 
should be formed and wants to have a call for members. But I don't want 
people to say 'great' and then nothing happens.

Dan: It is part of our charter. And people are willing to put in some 
effort....

John: I want to recommend a subcommittee approach.

Dan: OK.  Do people want a meeting next week to discuss XHTML next week?

[group yes]

Dr. Leff: There will be one agenda item, XHTML2 and what role does it 
play?

Dan: We will see how it goes and schedule form there.

Zoran: for the sake of efficiency at the next meeting, could you send 
us some bullets. If you have time that would help us be mentally 
prepared.

Dan: Anything else before adjourning?

[none]

Meeting adjourned.