[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Compromise Contract Structure, and Req #106
All,
I've thought more about Jim Keane's question -- whether another proposial can
combine the best of both worlds. Since "Section" is in both hierarchies, let's
try to leverage that, and address my basic issues: (1) Poor naming of lower
levels under "Section" (2) no "Clause" element and (3) No flexibility at upper
levels... Does this look alright to everyone?
<Contract>
<Paragraph></Paragraph>
<Article>
<Paragraph/>
<Section>
<Paragraph/>
<Clause>
<Paragraph/>
<Clause>
<Paragraph/>
</Clause>
</Clause>
</SubSection>
</Article>
</Contract>
Rules:
1. Paragraphs contain NO captioning elements.
2. Articles, Sections, and Clauses contain captioning elements.
3. Articles and Sections are not recursive elements.
4. Clause elements are recursive -- useful for levels 4+.
5. All elements may occur multiple times
This reduces the number of CSS selectors from 26 to 9:
Contract Article
Contract Article Section
Contract Article Section Clause
Contract Article Section Clause Clause
Contract Paragraph
Contract Article Paragraph
Contract Article Section Paragraph
Contract Article Section Clause Paragraph
Contract Article Section Clause Clause Paragraph
Now, this proposal does not yet address FrontMatter, Body, and BackMatter. I
propose that the structural elements, above, may also appear in any of those
elements eg
<Contract>
<FrontMatter>
<Paragraph/>
<Article/>
</FrontMatter>
<Body>
<Paragraph/>
<Article/>
</Body>
<BackMatter>
<Paragraph/>
<Article/>
</BackMatter>
</Contract>
==================================================================
I also MUST put onto the agenda for the next telecon the following, urgent,
question:
In Requirement #106 from Jason Harrop, is the "stylesheet" there referenced
referring to an XSL stylesheet OR a CSS stylesheet? The requirement now reads:
"106. Formatting to be handled via a stylesheet, which typically will apply to a
class of documents. The document author must NOT (emphasis added) be able to
change the formatting (ie override firm style) by applying formatting directly
to a clause."
The importance of this question is that, if CSS is a recognized stylesheet
language, then there are at least three extremely important consequences. The
standard contract datastream must therefore:
1. contain elements that correspond to every string of text shown in the
contract
2. contain elements that are reasonably in the same order as their order of
presentation
3. contain elements that facilitate the proper formatting of the contract
I also would add that all elements should allow class and style attributes to be
specified, which directly contradicts Requirement #106. I am very concerned that
this requirement to prevent modification of presentation styling is much more an
application-level requirement, not an interchange requirement. I also add that
CSS is an extremely important W3C standard, not one built just for HTML.... it
was built for direct display of XML datastreams, and for display of XHTML
datastreams created by XSL-T stylesheets.
Personally, I am resolutely in favor of supporting CSS -- in the manner of the
consequential requirements I outline above -- but there are other reasons beyond
a simple declaration of support for the W3C's long-established CSS standard, the
most important of which is that the opportunity for fraudulent mischief is too
great with contracts that are generated by programmatic application of an XSL
stylesheet to an XML datastream. I simply do not want to be party to a standard
that allows contract clauses to be included/excluded, or their text to be
determined, programmatically. My objective is to minimize absolutely the
probability of repudiation of a contract encoded in conformance with the
standards that we are developing.
If the workgroup decides that CSS support -- with the consequences outlined --
is critical, then I propose that Req #106 be worded as follows:
"106. All contract datastreams defined by this workgroup shall be able to be
formatted for direct display using the Cascading Stylesheet (CSS) language, as
defined by the W3C. No contract datastream may assume text that is or may be
generated programmatically prior to its presentation for signature using digital
procedures (in contrast to printed contracts). No contract datastream may assume
an order of XML elements that varies from the normal order of presentation of
those elements. No contract datastream may assume that content such as headers
and footers will be replicated during the display of the contract."
I urge us to create a standard that represents the entire contract, not much
more, and most certainly NOT ONE IOTA LESS. I urge us to resist creating a
standard for a datastream from which the contract is DERIVED using programming
tools like an XSL-T engine. If we create a standard from which the contract is
derived, then it's clear to me that we are not defining a standard for the
contract itself.
This issue is of critical importance to me, personally, for it is the one I
raised forcefully during our "chartering" and it was one that was deferred until
this "requirements phase" we're deeply within. This decision is necessary now
because other discussions, such as whether the standard will allow caption
numbers to be generated by the recipient of a contract that is coded in
conformance to the standard, depend in large part on its outcome.
I urge this group to require direct formatting by CSS of the xml datastream we
call an eContract.
John McClure
>-----Original Message-----
>From: John McClure [mailto:jmcclure@hypergrove.com]
>Sent: Tuesday, April 15, 2003 12:01 PM
>To: legalxml-econtracts@lists.oasis-open.org
>Subject: RE: [legalxml-econtracts] RE: Proposal: One container per level
>in the clause hierarchy (was Re: [legalxml-econtracts] Caption Numbers)
>
>
>Hi Jim,
>The reasoning is that we need to do as little injustice as possible to
>users' own vocabulary -- this means element names like "Sub2Paragraph"
>are pretty suspicious. If it is granted that that name should not used
>at least for that reason, then what is the replacement name for the
>levels below the third one? There are LOTS of examples of 4+ level
>structures in Findlaw's library of contracts, so the need for more
>than 3 levels is amply demonstrated. Hence, I suggest SubSection,
>SubClause, and SubParagraph -- each name very intuitive to everyone,
>each name clearly indicative that a parent is required, eg you can't
>have a SubClause without a Clause, and likewise for the others.
>
>The reasoning for rejecting Article is that it's silly in my mind to
>have a standard that doesnt have <Clause> -- so where would it be, at
>the top level? well, Clause is arguably the primary kind of block in a
>contract, and many many contracts have groups of clauses demarcated,
>so it suggests that Clause is at the second level.... so what is the
>first level then? I chose a term -- Section -- that is often used as a
>division of a document, focusing more on it as a container for clauses
>than as a type of text block itself but, due to its application in
>legal domain, CAN be a text block. OK, then the issue is, what about
>the blocks of text that are in a Section that are not parts of a
>Clause? So I say that a Section can contain Paragraphs, just like a
>Clause can.
>
>And I conclude that the 3 level structure is actually an
>"exo-skeleton" for the document structure, where each level can have
>its own sub-part, so we are able to simultaneously accommodate a 6
>level hierarchy without misunderstandings! I am very satisfied with
>this approach because it tracks nicely with an intuitive model of
>document structure, an exo-skeleton, each consisting of its own,
>internal skeleton, employed of course ONLY IF such is necessary to the
>document at hand. Yes, it creates hassles with some extra stylesheets
>-- but that I conclude is what the user community needs --
>flexibility, consistency with their own vocabulary, and an
>implementation of their own mental model of the document -- so that is
>what I try to deliver.
>
>Sorry, but I don't have an alternative to propose. In fact, I believe
>it was Dave Marvitt who suggested that we add yet another level --
>SubPart -- which I did put into the DC proposal, but honestly having
>fully integrated it into my own thinking at least... Dave was right in
>the requirement, but in my mind, we're beginning to skip into areas of
>presentation, and I am not intellectually fully there this moment.
>
>At this moment, though, when I am slopping real code, this approach
>seems to effectively gather together all that we have said and
>learned, after the 3 years we've been trying to figure out what a
>"Clause" is.....
>
>>-----Original Message-----
>>From: jkeane [mailto:jik@jkeane.com]
>>Sent: Tuesday, April 15, 2003 11:04 AM
>>To: legalxml-econtracts@lists.oasis-open.org
>>Subject: RE: [legalxml-econtracts] RE: Proposal: One container per level
>>in the clause hierarchy (was Re: [legalxml-econtracts] Caption Numbers)
>>
>>
>>What's your reasoning, John? Is there some pre-existing document structure
>>we can use as a model? What is your proposed alternative? And, I recall
>>this issue popped up in the Legislative work group where there are
>>definitely "Articles" in "Titles". Black's Law Dictionary (my shelf edition
>>4) has Articles of Agreement, Article of Incorporation, Articles of
>>Impeachment and even Articles of Faith.
>>
>>The fourth definition of Articles is:
>>"A contractual document executed between parties, containing stipulations or
>>terms of agreement"
>>
>>Some of the usage strikes me a applying to deeds in particular, but that is
>>just an impression. I personally feel its a bit archaic.
>>
>>The coolest use, however, is "Lord of Articles," defined as a committee of
>>the Scottish Parliament which gave the Crown a negative vote before a
>>debate. Alas, the committee was abolished in 1690 as inconsistent with the
>>freedom of parliament.
>>
>>Suggest sending a formal note to the Legislative committee about their
>>hierarchical
>>sequences.
>>
>>
>>
>>
>>James I. Keane
>>JKeane.Law.Pro
>>20 Esworthy Terrace
>>North Potomac MD 20878
>>301-948-4062 F: 301-947-1176 (N.B.: NEW FAX NUMBER)
>>www.jkeane.com <http://www.jkeane.com>
>>
>>
>>-----Original Message-----
>>From: John McClure [mailto:jmcclure@hypergrove.com]
>>Sent: Tuesday, April 15, 2003 1:23 PM
>>To: legalxml-econtracts@lists.oasis-open.org
>>Subject: [legalxml-econtracts] RE: Proposal: One container per level in
>>the clause hierarchy (was Re: [legalxml-econtracts] Caption Numbers)
>>
>>
>>>Can I suggest that for now, we work with the names agreed in the last
>>>teleconf, and come to a decision on whether a single label per level is
>>>sufficient and preferred?
>>>
>>>Separately to that, we could then re-open the naming issue if TC members
>>>wish to do so. Perhaps the best way would be for members to cast a vote
>>>in favour of one or other proposals to be made.
>>
>>All,
>>I think the names "Article" and within Article, "Section", to be
>>inappropriate
>>to the domain of Contracts. Those terms are appropriate in other settings,
>>granted, but not to the general Contracts domain. I see litte justification
>>for
>>artificial names like "Sub2Paragraph" used to represent subsequent levels. I
>>do
>>believe it is harmful to have an element called Paragraph and, apparently, a
>>child element called something like <p>. I believe it is a spectacular
>>failure
>>to create a standard that does not include the term <Clause>. I think it is
>>poor
>>to disallow Paragraphs within the Contract proper (but now I am discerning
>>that
>>they're sneaking back in through a <p> element that is presumably allowed as
>>a
>>child of the <Contract>)....
>>
>>So I move that we reconsider the names and structure of an eContract during
>>the
>>next telecon.
>>
>>===========================
>>other comments
>>
>>
>>> Now, I am assuming that none of your Section, SubSection, Clause,
>>>SubClause, Para, or SubPara correspond to the <p> which would be
>>>available in the model I have in mind. Is this correct?
>>
>>No this is not correct...
>>The name <Paragraph>, "Para" for short, is a <p>. All of them are blocks of
>>text, where any block can receive a caption and caption number. Wait, so a
>><p>
>>in your model is a different animal than the <Paragraph> you've identified
>>as
>>part of your Article/Section/Paragraph troika? Hmm
>>
>>>
>>>3. So the remainder of this message is based on the understanding that
>>>each of your Section, SubSection, Clause, SubClause, Para, and SubPara
>>>is a container, which can contain <p> (presumably more than one).
>>
>>Well yes, they each are a container for text, they each are a container for
>>other elements. It's difficult to visualize what the operative difference is
>>between a container and a non-container in your scheme. I am puzzled why you
>>have a <Paragraph> and a <p>.
>>
>>>
>>>Now, my comment:
>>>
>>>So, now, going back to just the clause model (rather than front and back
>>>matter as well), your top level element (lets call it level 1) is
>>>Section .. but at level 2, you have Clause Para and SubSection.
>>>
>>>Why can't we just have a single label for level 2 (like Word, dare i say
>>>it?).
>>
>>Because a Contract contains Sections, a Contract equally contains Clauses, a
>>Contract equally contains Paragraphs, etc. I am not imposing the requirement
>>that a Contract MUST contain Sections, and a Section MUST contain Clauses,
>>etc.
>>This is from analysis of contracts, one that also conclude that "SubClauses
>>only
>>appear within a Clause" .... the same as the model that I am proposing.
>>
>>>
>>>I don't understand _at all_ why there is any need for three different
>>>labels for whatever block appears at level 2. Could you please explain?
>>> How does an author make his/her choice between them? What does the
>>>trainer teach?
>>
>>The choice for the label for level 2 depends in part on the number of levels
>>in
>>the document as a whole, and in part on what the user feels is most
>>appropriate.
>>If it is a 2 level doc, then there's only need for Clause and SubClause, if
>>that
>>is the terminology that is comfortable for the author. They also can use
>>Clause
>>and Paragraph, if that is the terminology they prefer. They could use
>>Section
>>and Paragraph. They could use Section and SubSection if desired.
>>
>>All we're doing is acknowledging the important words in the day-to-day
>>vocabulary of people involved with contracts in some capacity. So the
>>trainer
>>says to users of DTD-driven editors:
>>"Choose whatever name you feel appropriate, but be aware that the choice of
>>a
>>name can foreclose subsequent choices. You cannot choose a Clause to be
>>within
>>the Contract, and then have Sections within a Clause -- but it certainly is
>>Ok
>>to have SubClauses AND OR Paragraphs within a Clause, whichever one you, the
>>author, feels is most appropriate to the task at hand."
>>
>>>
>>>Put another way, you have SubPara at levels 3, 4, 5, and 6. This
>>>potentially means mapping a SubPara to 4 different styles. What is the
>>>attaction of this?
>>
>>To cater to the needs of users. The do not want or need to be given a fixed
>>inflexible structure.
>>
>>>
>>>> Of course, an organization
>>>> standardizing on a particular document structure could trim this number
>>down
>>>> pretty fast (eg note that 36% of these are for structures that
>>>include a rarely
>>>> used "SubSection")
>>>
>>>How do they standardise on a particular document structure when the DTD
>>>allows multiple structures? The DTD should standardise the structure!
>>
>>DTDs are normally constructed with parameter entities that can control that
>>kind
>>of requirement.
>>
>>>
>>>What they need to standardise (and currently do standardise) is the
>>>style applied to that structure. And we can and really should make this
>>>as simple as possible.
>>
>>Yes, I agree, but only to the point that we are not over-simplifying,
>>creating
>>anything artificial, or being unduly arbitrary.
>>
>>>
>>>> but the structure IS there for those who have the need. Now,
>>>> please know that I don't subscribe to Sub1Para, Sub2Para, and so
>>>on... those are
>>>> a recipe for user confusion to me... I suggest more common, less
>>tortured,
>>>> names.
>>>
>>>Call them whatever you like; just give me a single label per level. The
>>>only reason I said "Sub2Para" rather than SubParagraph2, is that the
>>>latter can be confused with a reference to the second of two consecutive
>>>subparagraphs (as in see paragraph 3 sub-paragraph 2).
>>
>>I do understand why you chose Sub2Para rather than SubPara2 -- but those
>>numbered names are nonetheless artificial and hence not user-oriented...
>>rather I suggest real names that people intuitively understand: Section,
>>Clause,
>>Paragraph, and within them SubSection, SubClause, and SubParagraph.
>>
>>>
>>>Regarding your suggestions below for the names, I want to stay out of
>>>this debate. I am perfectly happy to run with whatever names the
>>>lawyers (and others) in this TC want to adopt.
>>>
>>>The only thing I strongly favour is a single label per level.
>>>
>>
>>I understand your view. It can be accommodated through parameter entities in
>>the
>>DTD if that is to be a policy of the organization.
>>
>>
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]