Draft minutes -- eContracts October 29

[Dave Marvit <dmarvit@pacbell.net>]

Folks,

Another fast-paced meeting.. Please let me know if anything was omitted 
or distorted. I'll look forward to our next meeting on wed Nov 5th.

Best,

_Dave Marvit
Fujitsu Labs of America

------------------------------
Oct 29. 2003
eContracts TC
LegalXML  eContrcats TC
Draft Minutes
October 29, 2003 Conference call

In attendance:

Rolly Chambers
John McClure
Jason Harrop
Dave Marvit
Dr. Leff
Dan Greenwood
Peter Meyer
Zoran Milosevic

---
Dan moves to approve the Oct 22 minutes
John seconds

Minutes unanimously approved


DG: I'm hoping that we can have a fairly free form discussion but that 
we won't spend too much time on any one topic. With that, I'll open it 
up.

Dr. Leff: I was looking at the DocBook thing trying to convert the 
thing with the colors and had some real problems with the numbering.  
I'll send something off to the group.

John: Several weeks ago I sent out a note that demonstrated that it is 
not possible to link to presentation material without referencing the 
IDs that are placed into that presentation material by the style sheet. 
I was trying to establish what one needed to be able to do to be able 
to forcast what the links were.  What the demo showed was that the IDs 
that are placed on the elements that are processed by the style sheet 
are certainly not guaranteed to be in the output stream that is output 
by that style sheet. So… if we wanted to provide linking -- and I have 
described four alternatives as to how to achieve that linking -- the 
proposal that I most strongly recommended was to have a standard based 
upon the XPath expressions that are represented by the output of that 
stream.

If you were trying to link to clause 3.2 you would reference that by an 
XPath expression that would link to the second block within the third 
block. This is an alternative that does not require that the output 
file be generated ... I don't think having an ID based system for 
linking is a good idea as a result.   It requires a fair amount of 
calisthenics on the part of the user.

So, I re-raised the issue  -- re visit the decision made last Easter 
that we exclude presentation issues from our realm of discussion.

I believe that we can meet our immediate objectives by establishing a 
'block' element that is placed into the output stream. Given that 
element in the output stream we can perform linking based upon the 
position of these elements.

The other half of my proposal is that all of the information that we 
would like to maintain about the document and its clauses that arises 
during formation management and mediation would be kept in a separate 
file, per the W3C recommendations, that would be formed using RDF. That 
would give us the place to go crazy and develop our own dialect.  We 
can meet all of our goals if we establish the output stream

One last note is that my proposal is that we use XML namespaces. That 
has been out there for many years now.

DG: John, to bottom-line it, it sounds like you are reacting to the 
draft structural markup proposal and that you are making a suggestion 
of using blocks and linking at the presentation layer.

John: Yes.

DG: And re-using what is already out there

John: My reading of Jason's work is that XHTML doesn't have very good 
containment.  By using the block element we address the containment 
issue.

Jason: it really is a question of just where to start. We can start at 
either end, one end being the evidentiary contract document, and the 
other end being the authoring end.

At the authoring end, I can discuss what someone would want to do to 
draft a document in XHTML. But that's the wrong end.

John: I am not dictating or even suggesting that they do authoring in 
XHTML.  I am only saying that the output of their style sheets be in 
XHTML -- regardless of what dialect they use for the input.

Jason: What is the status of the output of the style sheet? Is that 
something you want to standardize?

John: I am not trying to standardize XHTML as the standard for 
evidentiary contracts.  I am trying to standardize when both parties 
want to use XHTM L - either when using a style sheet ...

Jason: And why does it need to be standardized?

John: So that we can link to it in a standard way -- by referencing the 
block elements.

Jason: So the idea is that people are going to have style sheets that 
generate XHTML that has this block element in it. Block is not 
standard...

John: Because it uses namespaces it is standard.

Jason: But if having a namespace is what makes something standard then 
you can add a namespace to anything you like. That would make anything 
standard.

You say that you want to standardize the output of the style sheet 
process. I asked you why you ..

John: I am talking about the situation where people are making an XHTML 
stream where they want to link to it

Jason: How would they author this XHTML stream?

John:: They would use one of your favorite XHTML editors... the normal 
process.

Jason: But it is not the normal process. Because it has this extra 
element … you have to have this extra block element. It is not XHTML 
raw vanilla.

John:: I agree that if one is trying to validate the stream with DTD 
technology then it comes up short:

Jason: Even if you use a schema, it is not XHTML  that you can open in 
an XHTML editor. As soon as you are in that world then the model that 
we have authored wind hands down.

Dr. Leff: I think we have a bigger issue which is how do we put other 
markup into the document. I see no reason why we can’t have a valid 
XHTML snippet inserted into the structural markup if the thing being 
expressed is best expressed that way. Perhaps it is math expressed in 
MathML, or chemistry in CML, or whatever.

Peter: I agree with Dr. Leff. But we can accommodate that in our model. 
This discussion indicates that we have been diverted from the path... 
We have been working on the scenarios and the ensuing requirements. In 
parallel we have been working on the structural model. Nothing I have 
heard form John alters the fact that I think we should be staying on 
that path. We have been getting a combination of requirements and 
design decisions.

There are any number of other issues, in addition to the one Dr. Leff 
just brought up, that we could be addressing.

Dan: Do I understand that you think we should not be on parallel 
tracks? That we should defer structural clause models until 
requirements are resolved?

Peter: No. I think that nothing John has said bears on having these two 
paths. We should not divert form the course we are on, the course that 
we agreed we should be on.

Dan: So you are saying that John’s proposals go towards the overall 
requirements of the TC and you don't hear anything that should impact 
the structural markup. You will pick up the rest of these issues, 
linking etc, in the requirements phase.

Peter: Yes, that's exactly what I am saying.

John: In terms of namespaces I find it interesting that Peter says that 
we may need to look at them while Jason is down on the whole idea.

Jason: I am not criticizing the use of namespaces. I am trying to 
understand how they fit into your model.

John: I really believe that we will save ourselves a great deal of 
trouble if we create a standard for eContracts that are created in 
XHTML that is agreed to by the parties of the contract. For those 
people who are creating contracts in XHTML, SVG, or any of the others, 
we are providing them our guidance.

This does have an impact on the structural model.  We don't need the 
structural model.

Jason: I have no problem with the TC providing guidance for things that 
the TC identifies as appropriate.  Where we differ is in our view of 
the importance of the structural model. I think that if we don't have 
it people will never create eContracts in significant quantities, and 
you think it is not needed.

If you think it is not useful, can you ignore the structural model and 
make use of the rest of the standard? I mean you don’t need to use it 
if nobody else does.

John: When you get to flesh it out it will overwhelm the stuff that we 
should be focusing our efforts on.

Dan: Do you think that we should put off our discussion of the 
structural model until we have the requirements resolved? In view of 
the history we have I believe that it is not productive to say that we 
should

John: As I said in the note, it is a matter of priority, I think. The 
first priority should be the presentation data stream. I'm not saying 
it is useless, I'm saying it is a matter of priority. If we focus on 
the non-presentation the other things will get lost. The 
non-presentation should be an effort for down the road.

Dan: I wouldn't say that comment is out of order, but I would be 
surprised if the TC, given its history and near unanimous decision to 
follow this path, decided to abandon, even for now, the discussion of 
the structural model. But, having said all of that, do you want to go 
to the list and move that we change our process to put structure later 
and have presentation first? That'd be the second time we have had that 
discussion.

John: That is basically what I have put to the list.

Dan: Would it make you feel more comfortable to do a straw poll to see 
if people would support that kind of approach? But if there turns out 
not to be a groundswell of support to change direction then I'd like to 
say that what you are saying isn't out of scope, but if you said it 
affirmatively to Rolly rather than pushing to change course, then it 
would be more in sync with the rest of the TC.

John: I'd be happy to do that. I have put out a lot of information 
about my proposal. I really am interested in moving our agenda forward 
as quickly as possible. I want to contribute to the solution.

What I am proposing is a stage of specifications. In the first 
specification I am proposing that we focus in 2 or 3 things that 
excludes markup such as the structural model that can be used to mark 
up a contract. I suggest that we focus on the important things which 
are linking -- important to the many people creating SVG and …

When I talk about the difference in the quantity of material, this TC 
has not been a terribly productive one, let's be honest. With the 
exception of a small number of people, has not been writing a lot 
either on or off the record. If we bite off something that we can truly 
handle such as the presentation stream that inserts one element and 
that's it, then focus on the metadata that has a dialect that lets us 
contain the metadata about that contracts and lets us leverage the 
skill set we have which is the legal stuff.

Rolly: Your focus is on consumers of an XML data stream, is that 
correct?

John: Well… the producers...

Rolly: Your focus in on getting the folks who will be consuming, 
processing and using the output data stream for any purpose, you want 
to get it usable for those people as a first thing to do.

John: Yes

Rolly: And Jason and Peter want to make it as easy as possible for the 
creators.

John: Right

Peter: Rolly is partially correct, but it is also about providing a 
foundation that will allow all of the other needs to be met. John wants 
to start at the other end and hence these are fundamentally different 
concepts.

John: I want to solve the problems that people have today, as opposed 
to tomorrow.

Peter: One very narrow problem people have today.

Jason: We have the other problems today too.

Dan: Thanks for that Rolly, that helps a lot.

Is there any objection to having a straw poll to provide some feedback? 
I would like to encourage you, in case other people aren't interested 
in changing the prioritization, to stick with it. The requirements 
definition is a now thing.

All in favor of changing the prioritization of the TC’s process in 
accordance with John's comments, please say aye.

[One ‘aye’]

Dan: Opposed, please say nay
[Several ‘nays’]

Although we could take a roll, let the record reflect that there is 
near unanimity on the no side, with one vote on the yes side.

John, I invite you to take part in the requirements process...

John: I want to know if anyone in the group found any of the comments I 
made are useful.

Dave: I'll jump in. I thought at the issue of linking - weather to the 
evidentiary contract document or not, was of tremendous utility.

Rolly: I think that what you said is valuable. I just don't want to 
change the path we are on procedurally.

Dan: I agree completely.

Dr Leff: I think we ought to keep this structural model as simple as 
possible.

Dan; What do you think of tables, as an example of something we had in 
the infamous requirement 11.

Dr Leff: We can import a solution. We can't reinvent all of the wheels. 
A lot of people need a simple structural markup, but we can do it all.

Peter: I agree completely. I couldn't imagine that we would reinvent a 
table model. Our approach is to work out the absolute minimal structure.

Dr. Leff: When I looked at the DTD it was only 1/3 of a page. I'd be OK 
if it expanded to a page.

Rolly; I do want to touch on something that John said. Should we create 
a namespace?

Dr Leff: We should be able to bring in namespaces..

Rolly: I hear that. But I'm asking if we should create our own namespace

Peter: Rolly, we may need to but I think it flows from the requirements.

John: Let me establish that you can't put that into the DTD.

Peter: You would assume that we need a schema, but that would flow from 
the requirements.

John: So what I am hearing is that there is no need to validate the 
data stream if we are allowing other namespaces.  If you want to bring 
other namespaces in then you can't validate unless you bring in their 
DTDs.

Peter: We can only address that after the requirements are defined.

Dan: On the business requirements side, Rolly, do you have the doc that 
Peter sent from our Sydney meeting collapsing down the scenarios into 
their business requirements? Does anyone have that handy? I was hoping 
that we could at leas do a quick sanity check and a gap analysis to see 
if anything was left out.

We made some "quick justice" decisions and I'd like to run it by the 
group.

Peter: I can list the categories from the draft. For what it’s worth I 
am wondering if it is appropriate to throw this at everyone at this 
point, or if it should be done as part of the requirements process.

Dan: I think that's fair. Would someone be willing to post it to the 
list?

Rolly: I can stick up a section of what I have drafted. I went to the 
document that Peter pulled together and went through the scenarios and 
some other items to try to condense down the section for the 
requirements document. The pieces that I am working on are continuing 
to identify requirements, particularly in light of all that came up in 
the last week or two. There are some parts that I wouldn't change 
before posting he whole thing, and I'm happy to post those.

Dan: That'd be great. I know that what we developed in Sydney will need 
to be iterated upon a fair bit.

John: To what extent is the structural model in the requirements doc?

Rolly: I have incorporated the 11 requirements as identified into the 
requirements doc. It is its own section.

Dan: So, what will be ready to present next time?

Rolly: I think that Jason and Peter have been waiting longer so I'm 
happy to let them go first.

Peter: I think there is a pretty good chance that we will be able to 
present at the next meeting.

Dan: Great.  Until then, meeting adjourned.