[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes Nov 19th conference call
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]