OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Draft Minutes Oct 15


eContrcats Technical Committee
October 15, 2003 Teleconference
Draft Minutes

In attendance were:

Rolly Chambers
Peter Meyer
Dr. Lawrence Leff
Jason Harrop
Dan Greenwood
Dave Marvit
John McClure
Charles Gillam
John Messing

Dan G: What is the status of the minutes?

Dr. Leff volunteers to check out what minutes we need to approve, if 
any, and to get them into a vote-able state for the next meeting.

Dan: I'd like to discuss a few matters before we get into the major 
content of the meeting. I'd like to nominate Dave Marvit as our 
representative to the legal-XML steering committee. Each TC should 
appoint someone to the SC.  I'd also like to open it up to other 
nominations...

Silence

Rolly: Moves to close nominations.

Vote: (Unanimous approval)

DG: We have a requirements doc and we have structural markup to deal 
with.
We have materials form Dan, Jason, John McClure, and Dr. Leff.

Given the limited time I'd like to work on the requirements doc today, 
and start on the structural markup for the next meeting.  OK...?

Anyone against...? No...? OK.

So.. we had a couple of excellent days of meetings in Sydney. Dave, 
Jason, Peter, Michael (filling in for Zoran), and myself. We also had 
Charles Gillam for the first day. Dr. Leff and John McClure were good 
enough to join us by phone for the first day as well.

A couple of docs have been posted as partial work product from the 
meeting in Sydney. We need to review them and do a gap analysis for a 
requirements doc. We aren't at a vote-able requirements doc yet.

 From a process standpoint, I'd suggest that we work diligently over the 
next few weeks to get the requirements doc and the structural markup to 
the point where we can work on them.  That will form the basis for the 
subsequent specifications.

As a management process, I'd suggest that we have a document owner. 
This person could put together a doc that represents all of the ideas 
and proposals. Is there agreement that it is time to work on a 
vote-able requirements doc. [yes]

I'd like to ask Rolly if he'd be game to be our requirements document 
holder.

Rolly: I'd be wiling to take a stab at it.

Dan: Zoran might be a good partner on this.  I view this as one of the 
most critical junctures of the TC.

Would this be a good time to review the high points of the requirements 
docs that have been put forth? Actually, Can I hand the meeting to you 
Rolly?

RC: Sure. Is there a template, a model for requirements that the group 
would like to follow?

Dr Leff. I have a partial template.

DG: I think that some of the other TCs had good concise and short doc 
templates...

Dr. Leff: We have accesses to IEEE documents that might be useful.

Peter: I can send you a template that we use...

Rolly: I suppose that something that tracks what the other TCs use 
would be best.

DG: It'd be good if all requirements could be tracked back to the 
scenarios. We should also note what is in and out of scope from the 
scenarios. It is also useful to have requirements that are NOT so 
philosophical that they can't be tracked forward.

Dr. Leff: We may also want to consider behavioral requirements; One 
should be able to display in this kind of browser, we should be able to 
exchange data between specific contact management systems, accounting 
systems, etc... We may decide that we are not, for example, concerned 
with getting data into garnishment systems.

John Messing: If we do that, then are we required to make that work?

Dr. Leff: Well, we have to convince ourselves that it could work...

Dan: Simpler is better, of course...

[Group discussion about what approach to take towards the requirements. 
Should we spec out everything, or start with a simple solution and work 
towards a fuller solution? Do we try to get everything worked out from 
the get go?]

Dan G: There is this concept I have heard of called the parking lot. As 
soon as we know that something is out of scope for 1.0 we put into the 
parking lot and don't worry about exactly what rev they will land in. 
We don’t try to prioritize out of scope requirements, but we do keep 
track of them.

John McClure: There are data requirements, process (or functional) 
requirements, and system requirements (what tools are required to use 
our standard). The way that the requirements section is currently 
organized doesn't support those distinctions.

Peter: These breakdowns are useful, but the most important thing is to 
get the requirements down. Sorting them, while valuable, can happen 
later.

Dan: I started feeling really good about our process after the document 
that you (Peter) worked on in Sydney -- the business level doc. Having 
an understanding of the underlying business needs is a great place to 
start.

So, John, what are you suggesting?

John McClure: I am suggesting that we include a data model that is 
developed from the scenarios... We have been providing a data model in 
our scenarios.

Dr. Leff: I don't understand what you mean by data model.

John McClure: It refers to what data elements we expect to be referred 
to by this model - Jason has stated that by referring to termination 
and so on I am encouraging us to create a formal database of data 
elements. It is about traceability...

Peter: It isn't clear that this is part of the initial requirements 
process.

Dan: I'd hate to spend time working on lower level information...

John: This information, which we were asked to include in the 
scenarios, should be included in the requirements doc. Personally I'd 
be very unhappy if all of that work I put into that scenario didn't 
find its way any further.

Dan: We have to do a data model and we have to do a requirements doc. 
Should they be the same doc?

John: Perhaps data model is the wrong term. Perhaps data dictionary.

Jason: On Friday in Sydney we had a discussion about the non-structural 
layer data types.

There is the horizontal (jurisdiction, indemnification etc...) that 
apply to all kinds of contracts. Then there is a vertical set, those 
terms that apply to specific contract types.

The list of data elements that apply to verticals is endless – 500 for 
banking, 500 for real-estate etc...

I'm with Peter in that making lists of data elements is endless and 
fruitless.  We need extensibility.

John: I believe that, in so far as the data consortium standard is 
concerned, information items presented there are relevant to the sale 
and leasing of goods in general. The scenario was not designed to have 
data elements that applied specifically to real-estate.  Saying that 
the data consortium scenario applied to a specific scenario is not 
accurate.

What you just had to say doesn’t resonate by virtue of the fact that it 
seems to close the book on a lot of work that has been done by various 
members of the group.

Jason: It is not intended that way. Let's say we have a few data models 
(sale of goods, real-estate and construction.) But where is the data 
model for insurance, banking, and where are they going to come from...?

DG: We had an almost impassioned meeting in Sydney in the hall at the 
hotel - Jason was suggesting that we have a generic set of semantic 
tags (termination clause and so on). If we even had a small subset of 
10 or 20 ... certainly everyone would agree with those. That seemed 
reasonable to me. Then Peter convinced me that you would never get 
agreement on them, and it would splinter the standard...

I think we should get a basic set that could be extended.  If we find 
like 2 or 3 specific areas (real-estate, software, and so on). But if 
we wanted to establish a generic set I think reasonable minds will 
differ.

Dr. Leff: There are some things that cut across. Party A owes party B 
something.  What that something is and how it is represented is another 
issue. This has to happen a certain amount of time after that happens. 
And so on.

Dave: Is it reasonable for us to provide  a spec that doesn't deal with 
any specific vertical?

Dr Leff: [Yes]

Dan: The other thing that occurs to me, Peter, is that eventually, for 
the non-structural markup, if we do anything it will not be structural. 
It will eventually need a data model.

Jason: We don't need to do that at all. We can come up with an 
infrastructural approach. If you want to tie our representation of a 
contract to a non-structural layer that says something about, say 
banking, then we could do that. Then the question for us is what do we 
put outside of that industry specific model.
With that in mind, the difference that Peter and I had is basically 
insignificant.

Dan: Do you think we should determine architecturally how to support 
that approach (containers and bridges and so forth) in the requirements 
doc?

Jason: Well, it depends whether or not people agree that this is a good 
idea.

I went to a presentation in Sydney on XBRL. They started by trying to 
get the mother of all schemas. After 2 years they realized that this 
wasn't going to work. They decided that they needed to allow different 
countries to do what they wanted.

The Xforms approach demonstrates an architecture that might work here.

Dan: Great. Rolly, we'll let you sort that out.

Rolly: Great.

John Messing: Should modularizing different areas be part of the 
requirements doc - rather than having Rolly try to solve the problem?
Can we find a method that solves that...

Peter: the process of getting through he requirements should be looked 
at in terms of the output -- what do people want to do and what will 
they be able to do when the standard is developed.  The first draft 
won't have everything that the final draft of the requirements doc will 
have.

Dan:  That doc was generated in a very brainstormy way. Everything was 
in there. Now we need to pare it down. I think we need to move the open 
discussion to closure.

There is one other administrative matter:  Based on the importance of 
the work we are doing, and how much needs to be done, we would like to 
propose that for a while (3 or 4 weeks) we move to weekly meetings. The 
purpose would be to have a quick forced march that generates a pair of 
vote-able docs for requirements and structural markup.

The proposal is that for the next 3 or 4 weeks, we meet weekly.

[Approved unanimously]

Dan: Thanks folks.

Meeting Adjourned




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]