[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-econtracts] Draft minutes Nov 19th conference call
I don't think I actually was at the meeting, though I am quoted. Could you please check the notes again? ---------- Original Message ---------------------------------- From: Dave Marvit <dmarvit@pacbell.net> Date: Mon, 24 Nov 2003 16:37:27 -0800 >Hi all, > >Here are the draft minutes from the last conference call. Our next call >is on December 3rd. That gives people a bit more time than they have >had lately to get back to me with any comments / corrections / >adjustments / excoriations on the minutes. Please let me know. And in >any case, I'll look forward to talking with everyone on Dec 3. > >Best, > >Dave Marvit >Special Projects Consultant >Fujitsu Labs of America >Fujitsu > >----------------------------------------------- >Draft Minutes >eContracts Conference Call >Nov 19th > >In attendance: >Rolly >Dr. Leff >Jason >Dave >Chares Gillam >Anders Tell (as an observer) >John McClure >Peter > > >Dr. Leff is acting Chairman in Dan’s absence > >Roll Call [see above] > >The group decided to defer approval of the minutes until the next >meeting so that folks can have a bit more time to read them. > >Jason invites Anders to introduce himself. > >Anders explains that he works for Business Collaboration Toolsmith in >Stockholm Sweden. He comes from eBXML. Anders is also a Swedish >delegate inside UN/CEFACT. Has been working with biz collaborations and >ecommerce for a while. > >Anders: The reason I joined this group is because I am a team lead for >project contracts and […?] I am aiming at creating unified business >agreements and contracts. > >I am trying to identify various types of groups in this domain. > >We are also conducting a research activity Dec 6th. On a Saturday we >will spend a whole day talking about contracting in general, and where >the research community is. On December 12th we will have a face to face >in Vienna. > >Jason: We are doing 2 things. We are putting together a comprehensive >requirements document. It addresses the totality of what the group is >trying to do at the moment. > >The second thing we are doing is trying to make progress on >representing the structure of a contract. We are interested in >representing in XML the kinds of documents that lawyers typically >draft. We want to both do clever things with them as well as >regurgitate them. We want to put on top of that structural >representation, the semantic, and meta information that can be layered >on top. > >What we are talking about today is the structural model. The TC has >been trying to come up with the best structural model for representing >the world of contracts, but also with an eye towards the fact that the >kinds of things you see in contracts are in other documents as well. We >are trying to put together a clause model that works for contracts but >would also have a wider applicability. > >At the moment there is an existing model on the table that captures the >existing structures of contracts rather well. The issue we are >grappling with his what you might cal the list sub-clause continuum. If >you have a list of text and you follow it with a bunch of text items: A >something, B something or other, C more text… > >There is the possibility of representing that 2 ways. Sometimes you >will look at this in a contract and say that is a list that is part of >a sentence. Other times you will see them and say that they are >free-standing items and can be used separately. At the ends of the >spectrum it is fine. But in the grey area the question is how to mark >it up. > >We are trying to see if the structural model –does it give people 2 >ways to mark it up depending upon where they are on the spectrum, or >should we give them only one way to mark it up regardless of where it >lies? > >The grammatical paragraph model is called that because it has an >element that tries to represent a grammatical paragraph rather than a >typographical paragraph. > >What I am suggesting is that a grammatical paragraph model needs to be >distinguished from a typographic paragraph model. You would capture >separately the list. The list would not be in the same paragraph as the >sentence. > >With the grammatical paragraph model when you say there is a list of >colors, r,g,b. In a grammatical paragraph model you have “here is a >list of colors, r, g, b”. The alternative is to say, here is a list of >colors” and then have as a sibling the list itself. > >I am suggesting that we do away with the grammatical structure >altogether. You always have the list as a sibling. > >The primary benefit is that an author never has to decide which way to >mark it up. The author never needs to decide to put list inside >paragraph. It will always be a sibling. > >We were struggling when to use the item model. When we tried to reuse >our item model in the context of a list we had to say … generally we >are making a distinction between lists and sub-clauses, but when you >say you are trying to put a sub-clause inside a list we are saying ... >we want to promote reuse of these items up and down the clause >structure. But if you want to reuse it in certain places we have to put >constraints on the clause model so it would make sense. > >If you have a list you would not want a sub-clause inside a list >because it doesn’t make sense hierarchically. > >We make this distinction between list and sub-clauses that we then have >to manage. A key insight form Peters document is that there really >doesn’t need to be a distinction between lists and sub-clauses except >in terms of how they are numbered. If that’s the only difference >between the two things from the author’s perspective, and that’s all >that they care about, then let’s represent these two structures the >same way and let them chose an attribute that lets them chose the >numbering one way or the other. > >Dr. Leff: I think that was an excellent summary. > >Jason: Thanks. > >Peter: Yes, I think that covers the basic issues. > >Jason: Well, I guess that people should then express their view on the >basic issues…. > >John McClure: And containers for lists…? > >Peter: It does present another view of a solution to the problem. There >are things I like about it. The complete simplicity and reusability is >very appealing. The ability to pick something up and move it is the >high-water mark on that point. > >But there is a range of things we need to take into consideration for >the model. 1. The removal of the grammatical paragraph container and >the implications of removing it. There are advantages - for the >authoring. One example is putting in a table. Where does it go? But it >does create potentially very sloppy data. To some extent it could be >controlled by the application. > >More concerning from my point of view, using a DTD model there is no >way to constrain the structure of the document. This model abolishes >the distinction between the narrative and outline. At all levels of the >document you can mix text content and items. > >This would leave lots of work for applications …That’s actually my >biggest concern – it allows people to create extremely ugly data that >would be hard to wok with. > >John McClure: Jason, the use list numbers. I take it that’s used to >distinguish between the items that are part of the narrative content >from those that are part of the outline. > >Jason: As you say, I went with “use list numbers, t or f?” because I >think that’s the simplest concept for authors. > >In Australia typically a document won’t distinguish between list >numbering and sub-clause numbering. You might have a top level numbered >1, then a level below 1.1 then the level below will be labeled A. >In America there generally is a distinction between a sub-clause and >numbering as a list. That third level might be 1.1.1 > >At the top of page 7 I suggested a number of names and values. >Attribute hierarchy = narrative or outline. > >If we want to enshrine this distinction between outline and narrative >this would be a good place. The author could simply pick. > >It let’s you number it as a list or a sub-clause. Maybe Peter has some >thoughts on what that attribute could do because it might solve some of >his concerns making a distinction between narrative and outline. > >John Messing: I am concerned about using the same element as the >container for lists and sub-clauses. There are wildly different >conceptual attributes between clauses and lists. It seems that the >objective is to overload a term, “item”. I am just reflexively >concerned about that. > >I tend to favor the HTML approach . I’m still not convinced that we are >saving the author a great deal of trouble by overloading the item >element with that dual function. > >Jason: I understand, and I have 2 comments. First, we’re very >definitely trying to overload the item container with the view of >getting reuse up and down the hierarchy. If you do value that reuse up >and down the heirarchy, then it helps to have one item that you can use >in those various locations, and it probably makes sense to have one >container. If reuse is not so important then the reason goes away. > >Second, we should start to explore what the completely different >attributes are that we might need to be worrying about. > >John Messing: Well, clauses, for example, might be getting pulled from >a clause library. It is not a sharp delineation between the two. But if >they are putting in a clause it seems that they should be putting in a >list element. If they are putting in a clause… > >Jason: If you just put in a list item without looking at text above or >below you often wouldn’t be sure what it was – list or clause. > >At Speed-legal we … we keep coming up against the fact that something >has been used as a list but it has every right to be stored as a >clause. The simple paragraph model allows you to be able to reuse it >all – even if you don’t want to be able to reuse them. > >It will be up to people to think about how these clause libraries work. >If you are someone who creates a simple list, with one word, you will >never want to use that in a clause library. And then, what systems do >you put in place to make sure that it isn’t put into a clause library, >or at least isn’t recovered form the library in response to a search? > >Dr. Leff: Managing references to obligations may also be an issue. > >Peter: I think that the issue is that the boundary between them is not >clear. Many things could be clauses or lists and that generally up to >the author’s preference and that boils down, generally, to how they >want to number things. > >So, I think it is going to get down to how people use it in practice. >You will have to apply metadata to it to determine if it is an >obligation or not. > >Dave: It seems that what is happening here is that as we simplify the >structural layer we are simply moving the complexity elsewhere. These >issues still need to be addressed, but they may be addressed at a >different level. > >Peter: I would agree with that. > >John McClure: So the cost of going with an item element is the loss of >a grammatical paragraph, is that right? > >Jason: No… In principle you could have a grammatical paragraph and an >items element. Peter’s doc had a grammatical paragraph that allowed you >to put an item in it or as a sibling to it. > >You could have an items container inside a paragraph or next to it. > >If you allow that items container inside the paragraph or next to it, >then you are asking the author to make a choice. This is equivalent to >asking them to decide if it is a list or a sub-clause. It isn’t the >item that’s at issue. It is if you want to get rid of these two ways of >doing things that you have to get rid of the grammatical paragraph. > >John McClure: It seems to me that if you want to establish a library of >clauses and other stuff it would be at the paragraph level. And if we >don’t have paragraphs represented that would make things more difficult. > >Jason: It certainly would. But my assumption is that it would be at the >item level. The claim would be that you are never interested in using a >paragraph in a clause. You are interested in using the clause, and >that’s what you want to reuse, and that’s what the metadata would speak >to. Item would represent the atomic level of reusability. > >Peter: I am not completely convinced of that. You can’t exclude the >reusability of paragraph level … it is not that common, but it could >happen. > >You get chinks of clauses that you want to reuse in signatures for >example. > >Jason: There is a whole question about the reuse issue and if that’s >part of the standard or not. We could standardize that or leave it up >to the individual vendors. As a vendor I would make item my primary >reusable object, but there is nothing in this model that would stop you >from reusing a simple paragraph, albeit not a grammatical paragraph. > >A good example is contracts that have a termination clause and a clause >about what happens after termination. Often you want to use those >together. I would be interested in having a grouping container that >would allow you to reuse two or three of them at once. If you wanted to >do that with clauses, you could do the same with paragraphs. > >That is the kind of stuff that we can layer on top of the basic model >after we have the basic model right. > >Dr. Leff: I’d like to point out that there may be other purposes for >grouping. > >[Dave comments that the grouping could exist at a meta-level and >therefore Jason’s model does not demand that items be atomic] > >John McClure: Well, I agree, Dave, that the grouping is really a >metadata issue. Jason, may I discuss you comments on XHTML2.0? You said >that there were a couple of problems in adapting the XHTML2.0 to a >simple from a grammatical paragraph model. The question I’d like to ask >is how adequate is XHTML2.0 as a representation of grammatical >paragraph model? > >Jason: I haven’t analyzed it form that point of view so I wouldn’t want >to comment in any detail. It comes back to the observations I made last >time around. 1. We ought to be trying to come up with our own ideal >model and once we understand what that can offer us and then compare it >to XHTML2.0. Then, whatever XHTML2.0 offers us in terms of the clause >model, it is still just the clause model. We still need to represent >the signature blocks and the parties and all of that. > >Now what I am saying is lets’s compare XHTML2.0 to A. a grammatical >paragraph model, and B a simple paragraph model. As I understand the >tradeoffs, a simple paragraph model is the one that appeals to me the >most. > >John McClure: Is my understanding correct that we could establish a >module that establishes those items as an add on to the ones provided >by XHTML2.0? > >Jason: Yes, we could. But where we end up fitting in the pantheon of >various compliance levels I’m not sure. We wouldn’t be a strict subset. >This comes down to – when you look at the totality of what we are >doing, how much of XHTML2.0 are we using and how much are we throwing >away because it adds complexity that we are not using. The second is >more of a marketing issue. > >John McClure: So you are seeing advantages of being associated with >XHTML2.0 as opposed to DocBook? > >Jason: Well, I do think that’s so. But I’m not part of the W3C so I >have no idea how far we are from completion. But it is a grammatical >paragraph model and I don’t think it is the best way to represent >contracts. > >John McClure: Yes, but we know that there is a lot of momentum behind >it. > >Jason: There are interesting things here. Remember that the whole >reason we are talking about XHTML2.0 in some detail is because it is >different from 1.0. And note that Microsoft has announced that IE6.0 is >the last version of IE as a standalone. I’d be wondering , from the >point of view of web page authoring, what’s so bad about 1.0 authoring >and editing that will make people move to 2.0 if and when it is >announced? > >John McClure: It seems to me that it would be a lot easier to sell >people on doing more of what they are already doing today then asking >them to change into a Legal XML orientation. > >Peter: I think that a lot of what John is saying is true. We have to >get these issues squarely on the table. The truth is that we don’t know >how it will shake out. But in the mean time we need something. XHTML2.0 >does impose this arbitrary boundary that both Jason and I think is a >hindrance. Its list model is terrible. Is it worth developing an >alternate model? I don’t know. But I don’t think we lose a lot by >putting together an alternate model that will be of use to a lot of >people. > >John McClure: If we had a clause model that incorporated a grammatical >paragraph model and a container for lists, that would address the >concerns about the proposals that are on the list. > >Peter: Well, you can take the model I proposed and translate it into >XHTML2.0, so that the fact that it uses fewer elements is not an >argument… > >What we are finding with all of these approaches... we are trying to >find something .. we are worshiping the gods of simplicity and >reusability, and a few others as well. We have to decide which of these >are the most important to us. > >Dave: So, what should be our next steps? > >Peter: I’d like to explore, with Jason and others on the list, some of >the issues that have been raised. I think we need a little more >exposition on how Jason’s proposal could be implemented . Let’s have >these issues put to Jason > >Dave: Given the Thanksgiving holiday we have 2 weeks before our next >meeting. That should give us time to generate questions for Jason and >also allow him time to generate responses. > >[Dan joins and moves to adjourn the meeting.] > >Meeting adjourned. > > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]