[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes Draft June 18 - v1
Folks, Below is my attempt to represent another meeting with rapid and heated discussion. I am confident that I have not done justice to all of the opinions expressed. Please let me know what I've missed and I'll revise the minutes as quickly as possible. Thanks, Dave Marvit Fujitsu labs of America dave@marvit.org -------- Draft Minutes (Version 1) OASIS LegalXML eContracts Technical Committee June 18, 2003 Conference Call. Summary: - Minutes of June 4th meeting were approved unanimously - Some discussion about scheduling around the ABA conference - Discussion about the requirements document - Discussion about the need for the specification to not impede fully automated systems by requiring the ability to render - Approval of the requirements document 9 to 1 with an understanding of the context generated by the discussion - Approval of section 3.2.2 describing a process to develop a clause model (approved by all with 1 abstention). ---------------------- The following were present: Rolly Chambers Dan Greenwood Barry Hanson Jason Harrop Jim Keane Dr. Leff Dave Marvit John McClure Peter Meyer Zoran Milosevic Greg Wiley (as an observer) Dan G: Moves to approve the minutes of the previous conference call (June 4th) Seconded by Jason Minutes approved unanimously Jim Keane suggests that we add the ABA discussion to the agenda. John Messing has scheduled an eNotary meeting on Wed and Thursday. Jim has rooms set aside for Friday and Saturday afternoon. Sunday there is an ODR meeting. We need to schedule around the business law meeting if we can. DG Next item “Report on Friendly amendments received.” Jason…? JH: There is really only one amendment, and it is from Dr. Leff. Dr. Leff: The application I suggested may not involve any printed display. (The information is being used between applications.) Therefore I proposed that nothing in the clause model should get in the way of the needs of people that don’t want to display the contract. One suggestion is to make that change in the minutes [rather than in the document]. DG: I think it should be addressed explicitly. DM: Why not put it in the doc? JH: It didn’t seem necessary to describe one thing that we are *not* going to do. DG: From my point of view there could be an inference drawn that everyone using the eContracts spec would be required to support a rendered, displayed contract. Considering the delays inherent in modifying the document it might be better to address the need by dealing with the motion when accepting the document [later in the meeting]. JH: That’s OK by me. DG: Could you think about some clean language for us to consider when we decide on adoption of the document? Dr. L: I’ll work on it. JH: Next is 3.2.1 Addition of Emphasis handling Rolly: If you are envisioning an emphasis element that could be used, I would rather see that called something other than emphasis. Emphasis implies formatting. JH: Sure. I wasn’t trying to name the tag... Rolly: OK. What about representing lists? Peter: The requirement that lists be represented is in there as a part of structures. JH: The things in part 11 are the things we need to develop more detail on as we develop the clause model. DG: At some point we will have to address the issue (especially for consumers and displayed contracts) that some parts of the contract need to be ‘conspicuous’. Do people think that is a requirement that belongs in this document, or should it be dealt with elsewhere? It can be addressed in a presentation-like way. Peter: I was trying, in section 11, to provide an indicative list rather than an exhaustive one. Jason? JH: Generally speaking I’d like to capture things we have thought of so that they are not forgotten. As you point out, it can be represented structurally or in terms of non-structural markup. JH: 3.2, the motions... Are people comfortable accepting the requirements document? Jim Keane: What about handling the quorum issue? DG: We are the TC. And we will bring the formalities up to speed in the next call... JK: I just don’t know what basis we have to make a decision... what are we trying to achieve? DG: We are trying to accept a set of requirements. Rolly: If anyone is troubled by what is being considered then they should be on the call. JH: Sergio and John Messing aren’t on the call, but everyone else that seems to be involved is on the call. DG: I agree that we have web-based tools, but this [the conference call] is a powerful forum. There are 13 people in the group. Jim Keane: I am just a bit concerned by the informality and the not following the procedures of OAISS. That said, I am OK with moving forward. DG: Fair enough. And we are dedicated to straightening out the administrative issues. Dr. Leff: Here is some proposed wording: It should be convenient to use the clause model for applications where the XML is the contract and is used as an exchange between applications and is not intended to be displayed or represented in printable form. DG: Can we make that clearer? Peter: I’m not clear as to what this means. Contracts are between people and ultimately people will be evaluating them. Dr Leff: Two agents can have a contract, or an automated purchasing system. Neither party necessarily knows what the other party is looking at. The only thing that is common is the exchange of XML Peter: The purchase order is a contract, yes, but we aren’t marking up contracts yet. We are only marking up the human readable parts. There is a lot to a contract (as we have discussed) that we aren’t marking up. Dr. Leff: But the clause model that we develop for the human readable part should not inconvenience the instances when people want to do other things with the schema. The upshot is that some things may be zeroed out. [Some display parameters may be set to zero.] Peter: What you want is that if your ‘XML only’ contract contains terms that are human readable then you want to be sure that the XML does not cause problems with the automated system. DG: I like the way peter phrased it. Paraphrasing: Assure that the structural markup does not inhibit the use of the standard for uses in non-human readable applications. JH: I’m not sure how the change we are proposing will affect things. DG: I’m not sure either, but as an automated contracting enthusiast I do want to make sure that we don’t inhibit that type of activity. Peter: We are taking up a narrow scope currently. By suggesting an XML only transaction, that may be out of the scope of what we are trying to do. I am a bit concerned that we impose a machine readable model on something that is human readable. Dr. Leff: I agree. That would be a mistake. But in the process of making a contract human readable we don’t want to inconvenience the users/development of pure machine applications. Rolly: But why is it difficult to say that we don’t want to inhibit machine-to-machine transactions? Peter: I don’t have a problem with it. But I want to make sure that I understand it. Dr. Leff: If one of these terms represents a unit of obligation, then it shouldn’t be nested in a bunch of levels... Jason: What we are doing here is marking up the paragraphs that appear on the page. When you start to talk about units of obligation then you are talking about the other thread, the non-structural mark-up... Dr. Leff: There may be a ‘body of contract’ tag and then a series of statements. Peter: The point is that we are marking up the structure and it is not intended to be interpreted in any semantic sense. DG: It seems that we are in agreement... Let’s go with the original motion as described in the agenda with the context of the discussion as represented in the minutes. DG moved to accept the proposal Jason seconded John McClure: I move to table this until we have a better understanding of the clause model issues. DG: is there a second? J McClure: Can we have discussion? DG: It isn’t a live motion until there is a second… [waiting... but no second] DG: I am in sympathy with your point but I feel pretty confident that we are in a good position to address it at this point, even in advance of completing discussion of all of the scenarios. DG: I didn’t second your motion not because I thought it was unreasonable, but because I thought it wasn’t necessary. John McClure: The first item that I think deserves discussion is the expansion of the scope of the TC beyond what was described in the charter. I think that this is an inappropriate vehicle to amend the charter. Peter: This point was addressed in the last conference. There was an implicit agreement last time and this was being formalized this time. John McClure: I wasn’t aware that we agreed to change the charter last time Peter: I disagree that we are changing the charter. DG: The charter gives us considerable latitude to change the requirements. John McClure: Perhaps, but we are tasked with representing contracts, not every conceivable type of document that could be generated. Peter: The argument is that there is no commercial basis for having a DTD that is contracts only. Our basic proposition is that you need a more general purpose DTD in order to gain adoption. That’s what’s driving this. If we go down the route [of contracts only] we are committing suicide. We are not in violation of the charter, we are simply doing what needs to be done in order to have a successful standard. John McClure: Item#2, this is a requirements document, and yet it does not allow for the markup of a... The reality is that this is markup for some other document, for some other document than the contract document. My suggestion as to how to address that particular issue is to qualify at a minimum that, wherever it states that is the requirement for a contract document, to change it to say that this is a requirement for the ‘pre-contract document’ As for making a standard that is useful: Understand that there are XML dialects that are used by browsers that are used to make presentations. (HTML etc…) It is that XML that needs to be annotated to represent the semantics. If we are trying to represent semantics then the issue becomes how to create a markup that is coordinated with HTML standards rather than developing our own. JH: Aren’t you talking about the non-structural stuff? DG: In the interests of time, if you could rattle down what other issues you might have... It would be good if you could put the things forward that you might have to say... John McClure: Happy to oblige. There is no definition of terms. I have no idea what is meant by many of the terms. I really do raise a flag about the proper way to write a requirements doc. It should not include rhetorical questions. It should be definitive (in the sense of defining). I’m concerned with the process. I thought that no XML was to be generated yet... Scope issue, the way it is written, the definition of process it outlines, and (most troubling) that it doesn’t address the most key issue – the contract (that it is a presentation artifact) and the XL representation. Peter: My basic point is that John is seeking to revisit the previous discussion of the TC. Also, there was an invitation to submit amendments and it is unfortunate that he didn’t do so. I’m not sure that it is productive to engage in the debate. DG: Does anyone else have comments? Dr. Leff: I think that the coordination with other groups is implicit in some of these concerns. If we are trying to interface with things like open office and court documents and so on, then we should be getting involved with those groups. DG: Can you see to it that this becomes an agenda item? Dr Leff: yes. John McClure: The vote last time was to close general discussion. I am not trying to open general discussion. DG: I want to be very clear that everything that you have brought up *is* in order. One of the things you said in particular I feel quite strongly about. I find it somewhat troubling that we haven’t gone through all of the requirements. However, given that this is structural and not semantic, I am not raising the issue formally. Although we have worked diligently we still don’t have a full understanding of the requirements – so I am keeping an open mind about it. Having said that, I am still in favor of the document. Dr. Leff: I agree Rolly: I agree. By approving the motion I don’t think I am giving up the right to come back and revise things. Peter: I agree, but I think it will help us if we have something that we can work around. Dr. Leff: This can become our statement of work. This will be Useful when working with other groups. John McClure: The fact remains that we are going back and undoing the ‘preliminary agreement’ or whatever the term, about hierarchical versus recursive models. There was a lot of work that went into that. Now we have been presented with a set of requirements to examine (that don’t have the quality or quantity of backup materials of the recursive model). And now, without much discussion from the group about the flaws in the hierarchical model, it is being tossed aside. And we don’t know where it is going because there are no examples. JH: I don’t think that this was tossed aside. We learned a lot through that process. DG: Are there any other comments on the motion? [none] All in favor of the motion that: The TC accept the clause model requirements document; 9 in favor, 1 opposed. John McClure: Point of order. This looks like the process that was included in the document that was just assented to. DG: Does anybody object to this process? Dr. Leff: I don’t object to the process, but I wonder how it integrates with the previous discussion. JH: Could you post anything you think is appropriate to the list? Dr. Leff: Sure DG: Any other comments? DG: I move to accept 3.2.2 JH: Seconded. Approved by all, with 1 abstention. DG: Other new business? [none] DG: It is my expectation that the next few meetings will be less procedural and more addressing the substance. If everyone could please review Rolly’s scenario in advance of the next call that’s be great. Dr. Leff: There has been additional slippage. What should we do about the forthcoming schedule? DG: For the purposes of saving people’s time, there is consensus of discussing the ORD scenario on the next call. We’ll sort out the rest offline. Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]