Re: [legalxml-econtracts] Compromise Contract Structure,

[Jason Harrop <jharrop@speedlegal.com>]

John McClure wrote:
> All,
> I've thought more about Jim Keane's question -- whether another proposial can
> combine the best of both worlds. Since "Section" is in both hierarchies, let's
> try to leverage that, and address my basic issues: (1) Poor naming of lower
> levels under "Section" (2) no "Clause" element and (3) No flexibility at upper
> levels... Does this look alright to everyone?
> 
> <Contract>
> <Paragraph></Paragraph>
> <Article>
>    <Paragraph/>
>    <Section>
>         <Paragraph/>
>         <Clause>
> 	<Paragraph/>
>                <Clause>
>                     <Paragraph/>
>                </Clause>
>         </Clause>
>     </SubSection>
> </Article>
> </Contract>
> 
> Rules:
> 1. Paragraphs contain NO captioning elements.
> 2. Articles, Sections, and Clauses contain captioning elements.

By "captioning element" i take it you mean heading.  Does it contain 
PCDATA, or your "<en>" element?

On the face of it <Paragraph> is not what we had in the teleconf, but 
rather, is like <p> as commonly understood?

That would be ok, but i suspect your content model for Paragraph is 
still your <en> element, from your previous post:

 >     <Section>
 >         <Caption><en>SectionTitle</en></Caption>
 >         <en>text for article, or is this text for a para in the 
article.</en>
 >         <Paragraph>
 >               <en>text for another para in the article.</en>
 >         </Paragraph>
 >         <Clause>
 >                <Caption><en>Clause Title</en></Caption>
 >                <en>text for section, or is this text for a para in the
 > section.</en>

As I think you explained in a previous post, that "<en>" element is 
twisting the structure to fit the requirements of CSS.

> 3. Articles and Sections are not recursive elements.
> 4. Clause elements are recursive -- useful for levels 4+.

So in essence you've replaced Paragraph, SubParagraph that the last 
teleconf was tentatively moving forward with, with a recursive Clause model.

So now we are getting closer to:

1. Article,
2. Section,
3. Clause (cf the teleconf's Paragraph)
4. Clause
5. Clause
etc

I say getting closer to, since the list of selectors you give below 
shows you still aren't proposing a single tag per level.

If it was a single tag per level, I could live with this.

But even then it would be far from ideal, since by mixing recursive with 
non-recursive, you don't get the benefits of either, just the disadvantages:

Disadvantages of non-recursive
- moving clauses between levels eg moving a Section to the Article level
- difficult to share/re-use clauses across documents (think clause 
library) since you need to always use it at the correct level

Disadvantages of recursive
- harder to write templates which format the level (you need something 
like [count(ancestor::Clause)=2])
- training issue for end users
- raw XML is harder to understand without pretty printing
- hard to use CSS to format

We would be much better off with a model which is pure recursive, or 
pure non-recursive. Either is fine by me, but I'd caution against a mixture.

> 5. All elements may occur multiple times
> 
> This reduces the number of CSS selectors from 26 to 9:
> Contract Article
> Contract Article Section
> Contract Article Section Clause
> Contract Article Section Clause Clause
> Contract Paragraph
> Contract Article Paragraph
> Contract Article Section Paragraph
> Contract Article Section Clause Paragraph
> Contract Article Section Clause Clause Paragraph
> 

So there are still multiple containers per level!

And if i'm understanding your model correctly, this is because you can 
always use <en> directly in a Clause, or Paragraph with an <en> child.

You still have 9 selectors, and that is with quite shallow structure.

Why not just:

Contract Clauses Article Section Paragraph XXX1 XXX2 .. XXXn

where the XXX have a name those with legal expertise care to nominate.

I suspect we won't be able to resolve this until we've decided whether 
reasonable support for CSS is sufficient support for CSS, or we want to 
jump through extra hoops in the hope of getting CSS output which 
approaches the quality of output which XSL is normally used to achieve.