RE: [legalxml-econtracts] RE: Proposal: One container per level in the clause hierarchy (was Re: [legalxml-econtracts] Caption Numbers)

["John McClure" <jmcclure@hypergrove.com>]

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