[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]