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

[Jason Harrop <jharrop@speedlegal.com>]

Hi John and all

This email suggests that we need to come to a decision on whether a 
single distinct label per level is what our hierarchy should be providing.

Please see below... what do others think?

cheers,

Jason

John McClure wrote:
:
> Hi Jason,
> I wasn't proposing 7 levels where "anything is allowed anywhere else".... seems
> your calculation of "720 templates" is based on a misunderstanding of my
> proposal. Let me try calculating a more realistic number of templates -- because
> it IS a good question -- that is based on the DC proposal of Section, Clause,
> and Para, within which are SubSection, SubClause, and SubPara, respectively. As
> mentioned, the DC proposal allows the Clause and Para within a Contract, and
> allows a Para within a Section.
> 
> Contract Section
> Contract Section Clause
> Contract Section Clause SubClause
> Contract Section Clause SubClause Para
> Contract Section Clause SubClause Para SubPara
> Contract Section Clause Para SubPara
> Contract Section Para
> Contract Section Para SubPara
> Contract Section SubSection
> Contract Section SubSection Clause
> Contract Section SubSection Clause SubClause
> Contract Section SubSection Clause Para
> Contract Section SubSection Clause SubClause Para
> Contract Section SubSection Clause Para SubPara
> Contract Section SubSection Clause SubClause Para SubPara
> Contract Section SubSection Para
> Contract Section SubSection Para SubPara
> Contract Clause
> Contract Clause SubClause
> Contract Clause Para
> Contract Clause Para SubPara
> Contract Clause SubClause Para
> Contract Clause SubClause Para SubPara
> Contract Para
> Contract Para SubPara
> 
> So there are only 25 templates, not 720! 

Thanks for setting out the possibilities you allows.

Some assumptions/clarifications before I comment:

1. In the teleconf we have only be talking about the clause model so 
far, ie the bit that follows your front matter and precedes your back 
matter, so in what follows I'll focus on that.

2. I'm not sure whether we are talking at cross purposes or not .. in 
the clause model that the TC decided tentatively to run with at the last 
teleconf, we only specified the names of the _containers_ at each level. 
  I'm presuming the container at each level (eg Article, Section etc) 
can contain multiple paragraphs of text, and/or the next level down 
container.

	I expect those "multiple paragraphs of text" would each have the same 
name irrespective of their level.  Call it <p> for the moment.


	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?

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

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

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?

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?

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

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.

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

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.

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.

> On the subject of names for these things. An "Article", within which you
> designate "Section" blocks, applies to laws (and regulations?) and to other very
> formal documents like constitutions -- I have rarely heard these terms applied
> to a contract, but likely only because I am not a practicing attorney. The
> common-man's definition of a Section would be something closer to a high-level
> division of the contract, than a numbered sub-block of text. And, judging by the
> useful statistics you gathered, I must echo your own conclusion that "Clause"
> seems a more acceptable cross-Anglo term than "Article".....
> 
> So I am requesting that, for the domain of eContracts, we use the very common
> term -- Clause -- rather than Article. We've been using the term for so many
> years now that it seems a little strange to suddenly trash it -- I simply don't
> understand the justification given in the FAQ..... part of our job I thought was
> to establish an operating definition for the term, not to surrender and say that
> it's too ambiguous for any good use. Is this something we could reconsider?
> 
> Regards, and a sincere thanks for your good work pulling together all the
> requirements,
> John
> 
> 
>