Draft minutes, Oct 22 teleconference

[Dave Marvit <dmarvit@pacbell.net>]

Folks

Our Oct. 22 meeting was another heated one. Although some of the points 
addressed in our meeting, and (hopefully) reflected in the minutes have 
already been obsoleted by subsequent email traffic, I would appreciate 
it if folks would take the time to let me know of any inaccuracies or 
omissions. My limited stenographic abilities combined with the rapid 
pace of the discussion has doubtlessly led to some errors in the 
content below.

Thanks and, as always, I'll be looking forward to our call on Wednesday.

Best,

Dave Marvit
Fujitsu Labs of America


eContracts Technical Committee
Oct 22, 2003 Teleconference
Draft Minutes

In attendance were:

Mark Feblowitz
John McClure
Jason
Dr. Leff
Rolly Chambers
Dave Marvit
Peter Meyer
Dan Greenwood

Note: Mark Feblowitz is joining us for the first time from IBM research 
in Boston. [Welcome Mark.]

Roll Called

Minutes:
Dr. Leff: I located the two minutes that were outstanding. September 
3rd and 17th. Oct. 15th minutes were sent out yesterday. Once all of 
these are approved we will be caught up.

Dave suggests that we vote on the September minutes and the Oct. 15th 
minutes separately – since people have had less time to review the Oct. 
15th minutes.

Rolly moves to approve Sep minutes:
Unanimously approved.

The Oct. 15th are also minutes unanimously approved.

Dave: Any other administrative matters?

Rolly: I have taken a stab at a draft of the requirements using the 
OASIS documentation template for the purposes of formatting. I haven't 
hooked up with Zoran yet, and I would like to run the draft by him 
before I publish it. I have reviewed some articles on drafting software 
requirements.
I have some background on who the users might be and the businesses. 
These are drawn from the scenarios.

On the requirements themselves, I have broken them into what I call 
general requirements for XML syntax for contract documents. I have 
added a section on what I call document meta-data requirements. There 
hasn't been much discussion on that yet. I have taken the structural 
markup requirements from the work by Peter and Jason. I am currently 
working on the semantic requirements.

Once I have done all of that, and Zoran says it isn't too bad, I'll 
publish it to the group.

Dave: My only comment is that thanks, and feel free to pass the doc to 
the group off line if you don't feel comfortable publishing it. You 
should consider us all resources as you work on the document.

Rolly: Thanks.

Jason: It is probably worth having a discussion on the procedure for 
moving forward on a structural markup.

Peter: There are discussions underway already. I posted something 
yesterday for John's consideration, and you [Jason] and I are having an 
ongoing discussion.

Jason: Yes, it doesn't need to be formalized. We need to decide if we 
need to pursue an RDF approach or one along the lines that we 
[Harrop/Meyer] are proposing.

Dr. Leff: A couple of us thought it would be a good idea to support 
multiple ways of marking up a contract. It could be RDF, XHTML, 
DocBook, or something else.

Peter: That approach does need to be considered. As to weather we need 
to support them all, that's a big step. If we can say that for this 
kind of an application this is the one we want to support... that will 
help a lot.

Dr. Leff: There really doesn't seem to be that much difference. I think 
that they map to one another rather nicely.

Peter: I don't think that's the case.

Jason: In practice you aren't going to support hem all. It's just too 
expensive. It imposes an enormous burden on the developers.

Mark: One clarification is that there is the issue of whether you have 
one XML serialization instead of none.

Jason: Yes, and we are talking about one versus none versus two.

Mark: Yes. If you have 2 then you have a proliferation of code.

Peter: Well... what we need to work out is what functionality we need 
to support. What do people in the legal community want to be able to 
do? That will provide the answer. Will multiple DTDs frustrate what 
they want to do?

John: Do you believe that the markup you are proposing can contain 
everything that is required for a contract?

Peter: Yes.

John: Well, if you make certain simplifying assumptions, the contract 
will not be paginated etc..., then yes - -the model you propose can 
support all of the content of a contract. Personally I don't believe 
that those assumptions are valid.

[Dan Joins]

Dan: Where are we?

John: We were discussing ... the next juncture is RDF or not to RDF.

Dan: You mentioned the decision point between RDF and the Peter/Jason 
direction. Is that ready for a straw poll?

Dr. Leff: What about DocBook, XHTML etc?

Peter: I think that's a different question from weather the TC should 
adopt its preferred standard for structural markup. We don't need an 
either or. Effectively we can have both.

Dr. Leff: The fact is that we are a member of an organization that is 
pushing its own standard which is DocBook.

Peter: But you have to look at the functions that DocBook is intended 
to perform. It isn’t designed to support the kinds of functionality we 
need. It has been around for a long time and, in my opinion, it is not 
going to find its way to users any time soon.

Jason: The proposal is that Rolly's document can have 2 requirements
First, that the semantic layer can apply itself to a variety of 
structural layers.

The second requirement is that the TC will develop a structural model 
of its own, one and only one of its own. I believe that this is what we 
need to decide as our next decision. Does that model need to be RDF or 
one that we devise?
The TC is going to hopefully decide upon one or the other of these. The 
one the TC does NOT chose simply isn't part of the recommended standard.

Dr. Leff: it could be one of many. XHTML, DocBook, etc...

Jason: We could decide that RDF is the thing that is going to get the 
TCs blessing.

Dr. Leff: If we are going to think of something else [not Jaosn/Peter’s 
model] to bless, then why put RDF as the alternative. Why not XHTML 
etc...

Jason: We are past that point. From our standpoint those other DTDs 
don’t cut it. There are a bunch of people that are working on editing 
systems that allow us to exchange documents. That presupposes that we 
are using the same schema and the same DTDs.

Dr. Leff: I'm saying that if we abandon the effort to develop our 
structural markup, and I'm not saying we should, then the only 
alternative is not RDF.

Jason: Agreed.

Dan: I think that Jason and Peter did a fair amount of due diligence 
looking at DocBook and others. John has come forth with an RDF 
proposal. The fact that there are other plausible ways to go forward is 
not very compelling, at least not to me at this point.

Dr. Leff: John put together a proposal showing that RDF is comparable, 
and I could do the same thing with DocBook. I'm not a big fan of 
DocBook, but it is an OASIS standard.

Dan: Do we need to make a decision?

Dr. Leff: I don't think so. I'm perfectly content that we go with the 
Harrop Peter solution. I have included that in my proposal, and I could 
do it with anything else

Dan: I appreciate that, but I am asking the question from a narrower 
point. As a TC making a standard, and we could turn out an RDF spec, or 
a spec that looked like what Peter and Jason are doing. Do you not see 
it that way?

Dr. Leff: I think we should go with M/H or we open it up. (Much like 
the recall election in California.)

DG: I see. Rolly, do you think it would be helpful if you heard from 
the TC as to weather you wanted to follow the M/H approach or keep it 
open before the requirements are elucidated?

Rolly: I would tend to be biased against an either or approach. I want 
to provide more context in the document so we don’t charge down one 
path.

Jason: What Rolly is saying is right. To put together the requirements 
doc we don't need to decide what the structural model looks like. We do 
need to decide how many there will be.

Dr. Leff: I could consider generating a DocBook proposal just to show 
that it isn't that much effort.

Jason: They all look quite different when you start trying to create 
them in an editor.

Rolly: There is too much choice when, as a document author, you are 
trying to create a DocBook document. I think what Jason and Peter are 
saying is that there is an easier way to do it.

Dr. Leff: What a bout using a subset of DocBook?

Jason: We looked at that. Even if you do cut out the 100 or 200 
elements that we don't care about you still have something that doesn't 
represent contracts very well.

Peter: The fundamental issue is that we are trying to get to a 
structural markup - and XHTML is not structural in the sense that we 
mean.

John: I am still struck that the H/M model doesn't support external 
citations.

Peter: We haven't addressed that issue yet. There are any number of 
ways we can address that and we don't need to use RDF at a low level.

John: There are far too many contracts that require reference to 
content that is beyond the content of the contract.

Dan: I was at a meeting yesterday with some heavy hitters and they 
thought that it was an important requirement to be able to link to 
internal content. They talked about a variety of ways to link into the 
interior of the documents for the legislative process. For what it is 
worth I think it would be of value to be able to do deep linking into 
contracts.

It does seem that there are a variety of ways to address that question, 
even anchors could do that, I think.

Dr: Leff: DocBook makes that hard. There was a move to reinvigorate the 
electronic citations group.

Dan: Thanks Dr. Leff. I know that Roger Winters agreed to chair it, but 
not much has happened. Even if they do get together, I'd recommend that 
we do what minimally works and make it extensible. The narrower we can 
keep our scope and the fewer critical dependencies on other groups we 
can keep, the better.

Jason: There are two things to talk about here. 1: Are we moving 
forward with a structural model, and if so, should it be John’s 
approach, or should it be the H/M approach. The second is the 
citations/linking thing. John raised that as a reason not to use the 
H/M approach. We can use that as a way to approach the first issue (RDF 
or H/M), or we can look at this separately, When we are talking about 
linking to something, what are we talking about linking to? John is 
saying, I believe, that when we are linking we are linking to something 
in the presentation. We are proposing a structural model and I think it 
is perfectly obvious that you can link to that.

What John is saying is that to have a presentation format you need to 
render it on a screen, and if you use XSLT to generate that you can't 
link to the result. And all of that is perfectly true. But are we 
talking about what is the contract?

Dan: We have two parallel tracks. One is the structural markup, which 
is in a fairly advanced state. The second track is finishing up the 
scenarios and coming up with the requirements document, which includes 
the structural model. That includes issues of semantic models - 
possibly a few common terms, or many common terms, or no common terms 
and so on. That’s the purview of the document that the TC has asked 
Rolly to come up with.

What has been blurred is what the overall requirements look like and 
how that relates to the structural model that is currently in draft 
form.

There are two questions in my mind – procedurally. Do we want to deal 
with the structural model discretely, or not?

Or we could delay action on the structural markup and hold off on a 
decision about that until Rolly's doc is further along.

I would like to say that we have made a lot of progress on the 
structural model and I'd like to make a decision soon on the structural 
model. That's my opinion.  I'd like to hear feedback from everybody, 
but especially from Rolly since he is the requirements keeper.

Rollly: Maybe it is the tension between wanting to make a choice and 
not wanting to make a choice. I understand the need to make a decision 
on the structural markup.  At the same time, John's issues with the 
structural markup are well worth considering.

Dan: Let me list another option. We could vote for a structural option, 
but not as a final deliverable,  based upon what we know. We would 
reserve the right to revisit it if the requirements change the needs. 
This could form a foundation that we could work with. We generally 
don't re-open things, but we could reserve that right this time around.

Dr. Leff: It may be worth liaising with some other group on this 
linking issue.

Dan: By all means.

Jason: We need to be clear that this is not a general technical issue. 
It is a question of how we see our standard working. The business 
problem for our TC is: Are we linking to presentation formats or are we 
linking to structural formats? Carl Best is not going to be able to 
address that.

Dan: No harm in drafting a letter.

Any feedback on the procedures I outlined?

Jason, For what it's worth I think we should address the structural 
issue while we have the momentum and I'm OK revisiting it if we learn 
more from the requirements.

John: Jason said that I want to link tot he presentation of the 
contract, and that's true.  That's because the contract IS the 
representation. The vast vast majority of contracts that are of 
interest to us are presentation artifacts.

I have shown that you cannot link to material in a source document if 
the document is subjected to an XSLT style sheet. There is no question 
but that we are addressing presentation material. The resolution of 
this issue has a huge impact on the structural markup.

Dan: So john what is your take on the procedure?

John: I think that the first thing that must be addressed is that we 
should come to consensus as to

a: if external linking to internal content is a fundamental requirement 
and
b: how we will meet that requirement technically.

We need to finalize that consensus; the preliminary consensus that the 
presentation is out of scope for any discussions should be revisited. 
It is now time to resolve that.

Dan: Here is what I glean from you comments. It is time to clarify some 
of the decisions from the TC. We need to decide what to do with respect 
to linking into and out of the document. And we need to decide if 
presentation is in our out of scope, once and for all.

Peter:  I think that we settled on a process of doing the structural 
model first, before requirements. There is a risk and it should be open 
to adjustment and being revisited in relation to requirements that we 
later adopt.

These points that John raise are out of scope from what we discussed, 
but we simply haven’t addressed them. I think we can deal with them, 
but we don't need to use RDF.

John: And you will demonstrate that?

Peter: Yes, when I know what the requirements are. Then, if the 
requirements include John’s points, we can go and revisit.

Dan: Can I ask a question in closing. We have a meeting scheduled next 
week. The purpose of the next meeting is to get thing off of our desk. 
Which of you would like to present something to the TC for next week. 
If neither of you will have anything we may not want to meet.

Peter; I believe that we will have a something to discuss next week.

Dan: If you, Jason and Peter, can come up with a proposal for next 
week, would you, John and Dr. Leff be OK with that?

John: I have a real problem here. This RDF proposal is for a contract 
proposal document.  It is not meant to be used in any way for an 
executed contract. There is a fundamental architecture that is being 
implied here.

Peter: Ours is not for contracts.

John: I am at a full stop until I hear if external linking to internal 
content is a requirement.

Dan: Does everyone believe that that should be a requirement?

Peter: I don't know what that means. How do you link into a piece of 
paper?

Rolly: John means external linking into, for example, an HTML output.

John: Or, if our format is one that can be formatted using CSS then the 
content can be linked to.

Peter: This is incomprehensible to me.

Dan: Yeah, I hadn't thought of that as a requirement. I think it could 
be a nice to have

Roly: What do you want to do with those external links?

John: I want to put them into letters, I want to use them in 
mediations, I want to show a link between a charge on a bill into the 
clause that permits that charge. This is the web we are talking about 
and the web is all about linking.

Dan: You have unique ID tags for each item, right?

Peter: Yup.

Jason: All of the things that John has cited could be done with our 
IDs. The difference is that he isn't linking to the contract because 
the contract is the presentation mode.

Dan: We can still go forward, I think you don't need to be bin 
full-stop mode. My inclination would be to let people decide based upon 
what we have next week and if we supercede it later, that’s OK.

John: A week ago Jason requested that I demonstrate using the RDF 
markup using open-source. I agreed that I could do that as long as he 
addressed the issue of the linking. That should resolve my full stop. 
Yes?

Jason; I don't know if it will resolve your full stop, but I do agree 
that it will give the TC a way forward.

John: One last comment. I have been waiting since Easter to get this 
resolved. This isn't being sprung on anyone.

Jason: Why don't we spend the next meeting discussing this issue that 
is near to John's heart? John has asked if I am responding to this 
issue, and yes I am. That should give us something to talk about.

Dan: Will we have something decisionable?

Jason: I don’t think we will have something until the following meeting.

Dan: Rolly, are you OK with pour discussing that, recognizing that this 
feeds into the requirements process?

Rolly: Oh, yes.

Dan: Great. And Rolly, if you could have anything else you need to 
discuss in terms of requirements ready for discussion in the next 
meeting…?

Rolly: Yes.

[Discussion about next week’s agenda]

Meeting adjourned.