Draft minutes Nov 12th conference call

[Dave Marvit <dmarvit@pacbell.net>]

Hi all,

Here is another set of Draft minutes.  Please let me know if there are 
any errors or significant omissions. Apologies for getting out the 
minutes so late. It has been a particularly hellacious week.

best,

Dave Marvit
Fujitsu Labs of America
Fujitsu


Draft Minutes
eContracts conference call
Nov 12th conference call

In attendance:
Dr. Leff
Jason Harrop
Dave Marvit
Dan
Rolly
Peter Meyer
John McClure
Zoran


Dan notes that October 29th and November 5th Minutes have yet to be 
approved by the TC.

John McClure moves to approve the minutes.
Dan seconds

The minutes are approved. (All are in favor with one abstention.)
-------------
Dan: The clause model discussion is the major agenda item. Peter…?

Peter: I don't need to go into too much detail because the document is 
fairly thorough.  I am basically proposing a minimalist approach for 
now.

We can have a single structural element called an item that can contain 
other objects, and it can be used anywhere in the document.

It describes two hierarchies - directly recursive (item inside an item) 
and narrative - para and block inside an item. The basic treatise of 
the proposal is that we don't need any more than that. The hierarchical 
relationship is all that we need.

What it boils down to is that everything comes down to -- everything 
flows from the view of the simplest structure we can identify.

I have attempted to explain that, to provide some examples.

To the extent that it is not clear when you cross over between the two 
models, and it is not clear, I have tried to provide some indications 
to when authors would chose one over the other.

John: I found it to be extraordinarily useful. It helped me to 
understand the issues in detail as Peter understands them. I now 
understand the difference between narrative and outline as Peter 
describes them. It is not only a mater of title, but of the use of list 
elements to define document structure.

Peter: The issue that came up, and it was a difference of view between 
Jason and I in our early discussions, was weather you need a list item. 
It is conventional in DTDs. The question is “what is a list?” Things 
can look like lists in either context. The choices the author will have 
to make can be based upon “does it have a title?” But that is not 
decisive, and how do they want it to be numbered?

The concept of a list is relatively meaningless from the point of view 
of markup.  From the narrowest conception, a series of items in a block 
is a list.

But a bulleted series of items can be considered a list.  I want to 
avoid that distinction. I want to avoid having to call something a 
list. You know what you need to know by the hierarchy of elements. You 
don't need a list element to define it as a list.

That was one major discussion, that it is an elusive boundary and we 
didn't want to represent that in the markup.

John McClure: The second fascinating item was the introduction of XHTML 
2.0 as something that could be applied to much of our requirements.

Peter: Well, we have to take it seriously, definitely.

John McClure: So what issues do you see associated with XHTML 2.0 – 
given that it isn’t approved yet, although it is on a path with a very 
definite ending and likely to be approved as an RFC?

In my view there are 3 issues about XHTML. First, the 'l' element. […]

Second, there was no element that represents a number.

And third, the narrative versus outline issue that you just discussed.

I did some research. The second issue, the lack of the element holding 
a number - they are considering adding NR as an inline element. If that 
is indeed the case, and if the first issue is more a question of style, 
then could the third issue somehow be finessed? If so, then could we 
use XHTML as a solution to our problem?

Peter; Well, I only became aware of XHTML 2.0 late last week. I was 
quite surprised. It is clearly, from a business point of view, a major 
development.  It does create a risk for us in terms of how much we want 
to create a competitive model. The power that will come from the W3C is 
substantial. And as to how much I don't like the representation of 
lists -- well, that really won't matter.

I don't know what the implications of it are or are likely to be.  We 
have done a fair amount of work on our own to develop a clause model 
for the standard, and there are good reasons to continue with that 
work, but ... There is probably a fair bit of a ways to go before XHTML 
2.0 is approved, and what we are working on is compatible. It would be 
fairly easy to translate to it.
I'll be frank; I don't know what we should do.  I would be interested 
in hearing what others have to say. My position is that I would be 
happy to continue going forward on our work, but we may also want to 
reconsider our priorities…

Dan: We have gone so far that we may want to bring it to a vote with 
the understanding that we know we will revisit it at the end of the 
requirements doc anyway. If something develops with XHTML, or if we 
think better of it, then OK. We will also have something to compare 
against XHTML as it goes through its own evolution. I think it makes 
sense to bring this to a tentative closure and not let it fade away.

Dr. Leff: My understanding is that the actual DTD is quite short.

Peter: Yes, that was the objective. I believe that what we are putting 
forward is considerably superior to the XHTML 2.0. But, of course, our 
model will get more complicated as we get to the point that we can mark 
up an actual contract.

Dr. Leff: As things get more complex, people will be bringing all kinds 
of things in.

Jason: What we have on the table is a clause model for representing  
text. What you [Dr. Leff] are suggesting is that when things get 
complex enough for a contract user to actually use the standard ... it 
should clearly be able to represent a table - perhaps with a CALS model.

Jason: No one suggests that we need to create something the size of 
DocBook to represent contracts... If I can go back to the XHTML point, 
I just would like to say that I agree with Dan. There is a lot to be 
said for us making what we think is the best possible representation of 
the structure so that at some point if XHTML gets to the recommendation 
stage we can compare what we think is the best representation against 
the XHTML 2.0, and we can compare the benefits and tradeoffs.

As for the clause model proposed, it is just a few lines long and 
represents just the nucleus that we need to add to. If we find that 
XHTML is superior we can just slot that it. We will still have to deal 
with the rest of the issues associated with the contracts

Zoran: It is these other things that I am impatient to start working on.

Dan: You mean the semantics

Zoran: Yes.

Peter: There are bits of the clause model that we need to deal with - 
quotations and the like. But by and large the points that Jason makes 
are good ones.

Dan: The current draft for XHTML 2.0, it has some ways of representing 
other schemas and DTDs - so that you can lay our semantic layer over 
their structural markup. Right?

John McClure: Yes. We wouldn't have to have our semantic markup on top 
of their structural markup. We could have statements about the document 
as a whole including who the parties are, consideration, events etc. 
There is ample opportunity for us to provide some substantial work by 
working out what the format of the RDF file might be in order to 
exchange that in addition to the structural markup.

When we talk about the structure, there is the issue of the structure 
of the document as a whole (including references and attachments) which 
XHTML does not deal with well, and which I feel should be dealt with in 
some kind of envelope).

RDF information could equally address the more principle issues of the 
representation of the data stream when people provide their assent. 
Given that so much information is added at that time.

Peter: One point on that.  I think Jason's point is still the one that 
is critical, at least for the moment. The clause model is basic for 
representing the very lowest level of the contract, but we still need a 
number of other structures specific for contracts before the semantic 
layer. XHTML doesn't do that so that the work is still much the same.

Dan: Could you see a structure where XHTML is the bottom layer with a 
layer that we add on top, and then a semantic layer on top, or could we 
get all of the structure out of XHTML?

Peter: It could be either. We do need to pay attention to the 
commercial acceptability of the work.

XHTML 2.0 does provide a modular…

Dan: Is Fujitsu a member of the W3C?

Dave: I'm not sure.

Dan: Well, MIT is. And we can have a voice directly as to our thoughts 
on the shape of XHTML 2. We would be in a stronger position to do that 
if we have finished our statement about contracts. Then we would be 
able to...
This all brings us back to the point of what we should do with respect 
to structure.

Dr. Leff: I am already comfortable voting for the 5 lines of DTD.

John McClure: I believe that the DTD would be ...  I am a bit concerned 
about elevating it to a normative status because it could be 
distracting form the message we want to communicate. We don't want to 
distract from our willingness to…

Peter: XHTML 2 doesn't preclude people using another DTD, nor does it 
say that it isn't a good idea. XHTML has always been a bit of a messed 
up standard. I think it is a bit early to go with XHTML 2, but we 
should keep an eye on what is going on out there.

Dr. Leff: I think we ought to make a decision now about what people 
should be using for the (?)

John McClure: How about this… The item maps to the section, text to the 
l, block to the P tag. Perhaps we should adopt the names that the HTML 
set is using. By so doing we would be creating our samples in a way 
such that that they could be displayed using a XHTML 2 engine.

Dan: So you are saying that we should swap out the tags with the X2 
equivalents?

John McClure: Right. And I acknowledge that lists are an issue, but P 
has changed. Or perhaps we could insert a list element that would track 
to something in XHTML 2.

Peter: That had occurred to me, but there is a principle of not using 
their names if we are not also using their content model. As you say, 
there is a ... what your proposal would do is turn it into their model 
because we would lose this element that could occur in both the list 
and narrative models. In terms of having the best model in terns of 
simplicity and usability, that is what I wanted to represent.

If we do what you are suggesting you don't have the functionality I am 
proposing.  It is more like what Jason is proposing.

Jason: The presence or absence of the list container is one of the key 
points that we need to discuss. I don't think we have enough 
information on the table to make that decision.  If we do decide to 
have a list container then I think John’s proposal is an attractive 
one. If we don't have a list container, which is Peter’s preference, 
then any XHTML proposal would be very much in order.

John Messing: How do you distinguish between list items in one list or 
another list? How do you know that they are in different lists and that 
the numbering should be restarted?

Dan: You mean that if there are three lists, on a page, how do you know 
it?

Peter: They restart in each block or para element. The only issue is 
when you have more than one in a given para element. In that (rare) 
case, the application can deal with it.

That is the main argument that you need a list container. I don't 
believe that it is necessary, and I have given my reasons in the doc.

You will have to deal with that in a range of ways in the document. You 
can do that in the …

Dan: Are you saying that the application would know to renumber because 
when it sees a new block element it would know to renumber?

Peter: Yes

Dan: Jason, John, what do you think.

Jason: This is a can of worms that might be best addressed on the 
mailing list.

Dan: Can we get this on the table then? Can someone put the issues on 
the list in email?

Jason: Since Peter’s argument is in his doc, I guess it falls to me to 
present the other arguments.

Dan: Is that OK with everyone? Peter, John?

Peter: That is correct. I have attempted to summarize them in the 
document, but it is incumbent on Jason to put forth arguments if he 
feels the need. We have been using this model for years and it works.  
We have been using it with CSS.

Jason: But it is CSS, right...

Dan : Hold on guys. I just want to see if this is a reasonable path.

Peter: Yes, I think we need to get the issues out.

Jason Yes it seems satisfactory.

John: OK.

Dan: This is a key issue. Please make sure that this is reflected in 
the minutes.

Dave: OK

John McClure: A contract is something indicated by signatures to a 
document. In the digital world I assume that these will be digital 
signatures. In my mind what is being signed is its own issue as opposed 
to the authoring, (e.g. the XML dialect we are proposing as a 
standard.) Even that is a problem when people use a standard that’s not 
our own. The point of standardization is what is contained inside the 
envelope.

People will take what has been generated by the style sheet and place 
it in the envelope.

My objective is to have the 2.o data stream placed into the digitally 
signed envelope.

Dan: That’s a fair point. I think that we can address that in the 
requirements doc, or in the envelope. Do you envision that it has to be 
in this bit of what we are doing? Are you suggesting an amendment to 
what peter said, or …?

John McClure: I am just trying to express that I am concerned that the 
structural model … the game is what is inside the d-sig envelope.

Dan: Thanks.  Dave, did you note that in the minutes?

Dave: Yes.

Jason: It might be worth talking about inline lists. Peter, do you want 
to address the issues in 11.7.1?


Peter: The requirements for inline lists is a bit unclear because we 
don’t have them in Australian documents. So we listed a bunch of 
questions there to see if they are common in other documents - and to 
see how people addressed them.

First, are inline lists common in other documents?

When you have a [paragraph of text and you want to list a series of 
points (ABCD, or 1,2,3,4) and there is no line break in between the 
points. More typically there is a line break before each point.

Rolly: In my experience I see inline lists with 2 or 3 items. 
Occasionally with the items I deal with, but more often with other 
documents, like pleadings...

Peter: Are they part of the modern form of authoring?

Rolly: I use them, but if it is more than three I move to the block 
type list.

Peter: Do you switch? If you go back would you add a line break?

RC: Yes

Peter: And would you do the reverse?

Rolly: Generally not.

Peter: And would you expect your word processor to number them?

Rolly: I might number them myself, but that's probably just habit. It 
is hard for me to say.

Peter: And if you were using a system like HTML where it was easy to 
put in the tags...?

Rolly: If I did it I would want to mark up the list and the items it 
contained for the semantic significance of the content more than for 
the structure of it. If I am going through with a highlighter, I am 
probably going to highlight the items in an inline list not because 
they are in an inline list, but because of the content in them.

Jason: People sometimes cross reference to those inline list items?

Rolly: I think that COULD be done, and it should be possible to do it. 
I wouldn't say it is common for me.

Jason: That lease that we were marking up cross referenced to in line 
lists quite often.

Peter: It makes sense that if they are there people would want to be 
able to reference them.

John McClure: I think that the point would be to provide emphasis and 
to relive the eye.  The expectation would be that these items would not 
be modified as much as the items in a bock list.

Peter: Would you expect that an author would mark them up?

John McClure: No.

Rolly: I use an inline list when I want people to see them as 
either-or, when it deals with a couple of aspects of a single idea. If 
I wanted to emphasize two different alternatives then I would say “1 
and then 2”.

Peter: I think going through the questions we had in the document... 
Would you ever create nested levels of inline lists?

Dan: I wrote an MOU today defining levels of membership. In the first 
clause I was saying that there are different levels of membership and I 
said A,B, and C, can do this…

Jason: See page 40 of the doc. If you took all of the carriage returns 
out that's what you'd have.

Rolly: To get back to the issue of sub-lists .. I have never seen that.

Dan: I can't envision the use of a sub-list as a part of an inline list.

Peter: And is it likely that you would use both in the same block or 
para?

Dan: Yes.  Well... I didn't, but I could have. I personally think I 
wouldn't do that because it feels a bit sloppy.

Rolly: I would probably have it in a block.

Jason: I'm pretty sure that the Hannover [lease] document does that. So 
we need to decide if we worry about that or not. Is it a legacy 
document so we don't worry?

I think realistically whatever we do, there will be some contracts that 
are out of scope.

Dave: Just because people can’t readily think of lots of examples 
doesn’t mean that there aren’t many. It just means that people don’t 
think about contracts that way.

The classic example is that if you ask if more words have the letter 
“R” as the first character or the third, most people will say as the 
first character. But that’s only because we categorize words that way. 
In fact, more words have “R” as the third character. I’ll bet that the 
use of sub-lists as part of inline lists is the same way, it is more 
common than you might guess.

Peter: I am a bit in Dave's camp on that one.

Dan: John Messing, who has apologized for missing these calls, he is 
the ABAs main liaison to Legal XML. Rolly is the main ... we have 
formal liaisons form the bar association. Part of that relationship is 
that we can bring any draft spec to these guys to review it. That will 
be an opportunity to have a review of any decision we make on this 
issue.

We could build in time to do another study... to get some law students 
to do a quick statistical analysis of certain types of things. Sort a 
huge sample of contracts...

Rolly: I think that the question is a good one. I will say what Dan is 
saying. If we did away with combining inline and block lists I wouldn't 
miss it as a drafter and certainly not as a reader.

Jason: We face the question then as to weather we need to sacrifice it. 
In some models of how we do this stuff it could be sacrificed. In other 
cases we get to keep it. Then we have to weigh the advantages of 
keeping it and see what the implications are.

Dan: What are the costs of supporting it?

Peter: You might need a new element set to do it.

Dan: Isn't there a more elegant solution?

Jason: If you had a list container then the list container could say if 
it was inline or block. You do get to support it, but you need to add a 
list element.

Peter: You could also say, if you have only one kind of list in a block 
or para, then you have to specify what kind of list you have in a block 
or para.

Dan: There is a balance there. Peter and Jason, has this been a major 
point of contention?

Peter: No.

Dan: So we are running a bit late.  How would we proceed?

Peter: I think we have done enough on inline lists.

Dan: Where are we with he next rev of the requirements doc?

RC; I haven't added in all of the comments yet. I will add John McClure 
comments, and I'll add some of the other feedback.

Dr Leff: So the next meeting would be the 19th, then the day before 
Thanksgiving. Should we skip that one?

[some discussion]

So, a meeting on the 19th... then the next meeting December 3rd.

[process discussion]

Dan: So we have a common understanding of how we move forward on the 
clause model. It has to work for all of us and we will keep working 
until we get there. I will drop down and get more into the details.

Peter: I'm happy with that. I just want to see the issues exposed.

Jason: Sounds fine to me.

Dan: Thanks all. Meeting adjourned.