[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]