Draft minutes. Nov 5th conference call

[Dave Marvit <dmarvit@pacbell.net>]

Hi all,

Here is another set of Draft minutes.  As usual, please let me know if 
there are any errors or significant omissions. I'll be looking forward 
to any comments, and to our meeting on Wednesday, Nov 12.

best,

-Dave

Dave Marvit
Fujitsu Labs of America
Fujitsu


Draft Minutes
eContracts conference call
November 5th, 2003

In attendance:

Dave
Dr. Leff
Rolly
Jason
Dan G.
Zoran


Dan G. Calls the meeting to order

Rolly: I used the OASIS template and Peter's document. I went through 
the scenarios and some of the other documents, I tried to keep an eye 
on some of the email exchange in th elast few weeks.   I tried to use 
the charter as a starting point.

The terminology is mine.. User classes and characteristics Much of this 
are just summaries of what was expressed by others.
I put what I cal tghe functional requirements into a section.  I broke 
them into general requirements -- which included a section on document 
meta-data markup that had been touched upion in a couple of meetings.  
I then incorporated the structural markup requirements that J&P had put 
forward.  I then took a crack at the semantic requirements.

As best I could I tried to list the scenarios that touched n various 
requirements. I may aheve not included soem one, but I tried.

As far as references, I just tried t find as many relevant standards as 
I coud. It is not intended to be complete.

My goal was merely to put the ball in play and let my team mates move 
it forward.

Dan: Can you take a minute to review some of the requirements. There 
were some shoulds and musts that might be interesting to discuss.

Rolly: Yes, some of those migh be subject to change.

There will probably be some disagreement about weather the stanbdard 
must be easy for users to learn and use, or should be easy...
Dan: Users was a litltle bit unclear to me.. who is that..?

RC: To me users are authors and developers of software applications.

Dan: You docukent seemed loose enough to imply that it might include 
end-users... Joe Schmoew lawayer looking at a web browssre.

Rolly: Yes, that's true.

DanG: I wonder to what extent the end-user will be insulated form that

Dr. L: Peter may be asserting that people will be seeing the XML. Am I 
understanding his point of view corredtly.

Jason: This #2 is interesting. Dan said that this implies that it must 
be easy for developers to create applications that re easy for 
end-users to use. But Peter may say that developers can take care of 
themselves. But I hate to speek for peter.

Today you can't completely hide our work from the end-users. Sooner or 
later they come head to head with markup. That might be right-clicking 
and getting a list of tags to insert.

even if they don't get so  many tags at that point, they will come head 
ot head with tags when they try to move some paragraphs around - they 
will be confronted with a structural outline.

RC: That makes sense to me, how abot you Dan?

DG: Yup.

Rolly: Rewquirement#5, This is th epoint that Dr. Leff raised -- it 
will be important for the semantic and structural markup to mesh well 
together.

Dr. Leff: Yes. Many menmbers have suggested that not only do they need 
to mesh, but they can go into other things. Someone wants to use our 
semantic m,arkup in some other context...

Rolly: Yes Dr. Leff. That's what I understood your point to be. I'm not 
sure how well I expressed it.

Jason: That sounds liek a different point to me. You are suggesting 
that end-users don't need to know what is going on behind the scened. 
Dr. Leff is sayingthat the two markups can be sued seperately.

RC: yes. Perhaps that shold be a seperate reqt. You coiuld use the 
eContracts structural Markup and use it with eBL or soe other system...

Dan: Oh, the modularity

RC and if we have soem core elements - some comon business terms, then 
it ought to be possible fo rother people to take those and use them as 
well.

It seems that different groups (airline, auto industry etc) could have 
fairly specialized tags and yet still have use for soem common terms.

Dr. Leff: Right and the concept of the oprdering of events, the notion 
of a duration of time and so on.

Jason: I was certainly thinking that the semantic model should be 
applical to the econtratc strucltral representation, or XHTML, or 
somehting else. I am not as sure about using the clause model for other 
things, although that is Peter's entire claim.

Dr. Leff: I think that ther e is a marketplace for structural markup 
for a variety of things. Something ike what peter meyersis proposing 
woudl be good to stick in the JDDS...

Jason: Yes, and that's fine, but I'm not sure how much we shoud go on 
about this given our mission.

DG: Persona;lly I like th eidea that, assuming we have a breakdown of 
STRUCTURAl and non s -- and perhaps an envelope, I like the idea of 
saying that you can use any part of it.

[envelope discussion]
it may certaibnly come inn hand at some point. If we talk to pointers 
to a contrct that are not your contract - not yours to put markup in, 
but people might enjoy commentingh on. There are systems that have 
links to licences. I am saying that I liek th eidea of having an 
envelope for things that we can't yet perdict.

DL: The idea of keeping track of offer and accetance, those kinds of 
ideas, migh tbe a natural for an envelope.

DM: use of envelope for partial offers (in out ANS)

Dr. Leff: That has played out in other cases such as with the insurance 
oon the WTC.
Libraries of clauses-- lexus nexus wants to see how certain clauses 
show up in court decisions.

DG: So was there concensus on weather the various parts should be 
modular (miux and match able) .. is that what you asked rolly?

RC: yes.

DG:

Jason: Modularity is a shorthand for statements such as: The XML 
semantic markup should be able to be applied to a wide range of 
different contrcatual representations, or 3rd party XML dialects should 
be able to be related

RC: How about the subject of the document meta-data? That's not a 
subject that has come up much or gotten much discussion. Both Jason and 
John McClure touched on the subject in their scenarios...

Jason; I am not clear oin the distinction between metadata nd semantic 
markup.

RC; Metadata os kind of a slipery concept. What I thinkof as document 
metadata is the kind of stuff that might be collected and used by a 
docuemnt mahanegemnt system. I go to the dublin core metadata 
management system. hwat I am suggesting is that that kind of metadata - 
metadata about the document- ought to be collected. The contract and 
buisiess terms (price, date) are distinct.

Jason; One of the questions about the ducument metadatya is weather you 
do it at the docuyemnt level, or at the clause level.  Do you want to 
be able to say that the IP clause was writtenn by so and so on dex 
11th...
Rolly: what I have put forward is at the docuemnt level, but I fully 
agree that it could be done at either or both.  I have no position or 
preference.

Jason: Do we wnat ot put a stake in the ground, or should we note that 
it is an issue fo rht eTC to discuss.

Zoran: I think it is a prety generoic concept. I think it'd be useful.

DG: Whats's the traceability to the scenarios?

RC: John McClure had the idea of using the dublin core at the document 
level.

Jason: We need to decide if we want to include.

DM: Right, so what is the down-side of including it.  Is it just 
feature-creap?

DG: Right.  That's why I was lookking for traceabuility. When I look at 
it this seems like the kind of thing we want o get out of the envelope.

Jason: Equally, I think that a document management system will handle 
anyway.   It may be that we can specifty what it looks liek so that 
when people make their databases they can use it. It kind of comes down 
to the issue of is the reuse mechanism part of this system or not.

Dr. Leff I think you are right about the C managemwent systems, but 
what about findlaw where they throw out contracts for people towrite up 
their own.

maybe we should put that in the parking lot. There are other examples, 
such as the exception processing.

DG: Since it soulnds liek there aren't any strong opinions, then is it 
OK if we move on...?

RC Sure

Dr. Leff: Right. I was syaing that we might ewant to consider 
eexceptioon processing. I don't think this is a version 1 issue, but I 
think we may want to provide that at soe point.  That is discussed in 
my proposal on the resources poafe.

Jason: Is ot true that w\hat you just said requiress a mechanism or 
model for modeling events?

Dr. Leff: Soenmone might say that for these 5 clauses, they must be 
interpreted strictly, like saying that these 5 dates are of the 
essence, or these things that I am saying I want in the building are 
essential.  I won't pay unless these are there.

Jason:  All of that stuff opperates on the legal level which is 
different form what I think of as exception handling.

Dr. Leff: Right. But we may want  to combine clauses by saying that 
theese clauses survive termination.

RC; I do agree with jason that sonme of the points being raised seem to 
be on th elegal level. I get humng up wondering who will tell the 
software, or how will it be told, that one of these events has taken 
place.   Force majeur events are events and they may excuse some or all 
of the contrcat

[discussion of representing events]

DG: I was wondering when we would come to this and I am glad that we 
have come to it now. For us, we have to decide if it is in scope.  It 
was certainly in scope to have it come upp as a scenario becaus eit is 
kind of an obvious thing to come up. One question is when do we think 
it will hit the market.

Z, your work assumes that checking for thse kind s

While this seems kind of exciting, and it seems liek it is kind of the 
point, I am sketical that the market is ready for that level of 
automation.

Dr L: In the work that I have done, including the interoperability 
paper, i assume that these are seperate standards.  This stuff is going 
to be somewhere else.  Whe may want to have some discussions about how 
to comnnect to this something else...

Z: This discussion  - we need to address seperation of structural 
issues from semantic markup. It can be simple thing slike price, date 
etc.. We can treat them seperately and link them to structure.
We can have an executable representation of obligtions and events.

I think that we should concentrate on the structural markup, then work 
on the simple semanticv (non-structural ) and work on linking the 
levels. Then, when we have a more advanced semantic structureal level 
we can work on linking

we need to start with the simple things

We can treat some concepts tat have already been raised as a simple 
semantic markup.

I am just proposing a way to deal with structural and semantic markup 
seperation and then deal with the semantic markup. There are various 
ways you can treat the relationship and seperation between

seperation nis important for evolvability.

DG: I am hearing some conservatism..

Z: It was not meant to be conservatism, but realism -- so that we can 
start with structural and then simpler semantic markup -- only then can 
we move on to more complex stuff.

DG: Sorry, I maent cautious and stepwise.

Dr L: Well, that's how programming languages developed. Fortran is a 
good example. That's the peoposal we have here. Put some basics into 
the standard and then t will be extended buy the research and business 
community and those thing s will be standardized when the time is ripe.

Z: Exactly. I'd liek to split the standard up into a few areas.

I can look at teh seperate bunch of expressions that are sitting in my 
semantic markup part and see if some part has been violated. the nI can 
have traceability

RC; If anyone wants to send along suggestions or revisions, either on 
the list or in email, that'd be a way to work on the next evolution.

DG: When do you think we could have it itterated to the point where it 
is votable by the group?

RC: From my perspective it woudl be when the group feels that it has 
had time to review and modify the document as appropriate. It is more 
dependant upoin the timetable of the group than my time table.

DL: I feel very comfortable witht he doc as it is. But it is important 
enough that we should give it some time.

DG: Next meeting is goiung to be P&J. I assuem that we will move back 
to the requirements doc the following week. The I'd like to be able to 
vote on it around that time.

Jason: I think we should consider what needs to be in it before we say 
it is complete and ready to go.  I'd say it needs to be tight enough in 
p[laces to constarin what the solution is going to be.  There is stuff 
in here ethta we would undertsand becaus ewe have been in the TC.,  
Rigght now there are not enough stakes in the ground to justify the 
solutions we chose.

If you look at #8, the solution designers have a lot of work to do to 
impliment a solution (date or time duration). Much of what ios bnneeded 
to understand this well is in Zoran's published papers. but leaving it 
to the sol,u

I thinkn about the semantic requirements: it is still left entirely 
open weather ot not our solution adresses items 1-12 all, or if it 
adresses the need for arbitrary semantics and by being able to address 
those we also happen to be able to tick those off.

DG: I think you have provided some metrics for us to meet before we get 
to a releasable document.

[Jason will send his more detailed suggestions to Rolly and potentially 
add them in]

DG: one area where we need more discussion is on the extent of the

Dr. Leff; There is also th eparametrcic