Re: [legalxml-econtracts] Draft minutes Nov 19th conference call

["jmessing" <jmessing@law-on-line.com>]

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.
>
>