OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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]