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

["Daniel Greenwood" <dang@mit.edu>]

Hi John, all,

The word "clause" gave trouble to participants from other
jurisdictions where it carried additional layers of meaning, as I
recall the conversations on our last couple of calls and perhaps
earlier.  Does anybody recall the details on why we were inclined to
shy away from the term "clause"?

I'm concerned that we not spend overmuch attention on this structural
question at this time.  While it will be critical to our standard, I
believe the most important substantive question at this point - what
are the underlying scenarios of use and hence requirements - are being
addressed by applying Jason's framework to our various scenarios.  I
propose that we all keep primarily focused on that and establish a
common understanding and agreement around the scope of our effort.
Based upon that, I predict the structural and other form issues will
be easier to address.

Thanks,
 - Dan

-----Original Message-----
From: John McClure [mailto:jmcclure@hypergrove.com]
Sent: Tuesday, April 15, 2003 3: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.
>
>
>