Re: [Fwd: [legalxml-econtracts] Variable Structure]

[Jason Harrop <jharrop@speedlegal.com>]

Hi John

Please see comments below...

> -------- Original Message --------
> From: John McClure <jmcclure@hypergrove.com>
> To: Legalxml-Econtracts <legalxml-econtracts@lists.oasis-open.org>
> Date: Fri, 11 Apr 2003 10:38:08 -0700
> Subject: [legalxml-econtracts] Variable Structure
>
> All,
> I apologize for being unable to attend the last 2 concalls, but I note 
> good
> progress is being made. I am particularly happy that the hierarchical 
> model is
> being chosen by the group. I do have reservations though about the 
> specific
> levels that are being chosen, and am wondering about the content of each
> level.... for instance, I see in the minutes that:
>
>> Point made that it could be difficult when a user wants to put
>> paragraphs directly under Articles, and skip having sections.  Of
>> course, sometimes users wish to do that.
>
This particular passage doesn't reflect anything which was discussed at 
any length in the meeting.

I don't think a user should be able to put a Paragraph element directly 
in an Article (ie skipping Section).  The reason I don't think the 
clause model should allow this is that I can't think of any example 
where it would make sense. Counter examples welcome :)

>
> It is this problem that I'd like to address.... The spirit of the 
> proposal from
> the Data Consortium suggests that an Article can contain Paragraph 
> elements, as
> well as Section elements; as well, a contract can consist of just 
> Paragraph
> elements, without the bother of Articles or Sections, a structure 
> appropriate to
> many contractual memoranda. This method is attractive due its 
> simplicity in
> terms of both DTD-driven tools as well as defining CSS stylesheet 
> selectors.

See above - if all you want is flat paragraphs to model a contract which 
only has a single level of clause, why not use Article?  That is what we 
are proposing to call a top level clause.

To recap what i put in my FAQ document, i think it is highly desirable 
to have a clause model which has one and only one thing at each level in 
the hierachy.  As soon as you depart from this, not only do you make 
things needlessly complex for the user, but for stylesheet purposes, you 
can't infer the level of something (and therefore how to number it) from 
its name (eg Section).

>
> Since I missed the meeting, this issue may have been discussed -- if 
> so, I
> regret again not having been able to participate.
>
> My second concern is the number of levels -- three levels is hardly 
> adequate to
> the needs of the commercial real estate industry. We have multi-part 
> contracts,
> with front-matter (title pages, tables of contents, covering memos), 
> body, and
> back-matter (addenda and attachments). The body of a contract can have 
> at least
> four levels of text blocks, although I feel certain that there are 
> contracts
> drafted with several additional levels .... 

We talked about having sub-sub-paragraphs, and sub-sub-sub-paragraphs, 
etc as deep as is appropriate.  You'll see in my FAQ document that i've 
used the form SubNPara, where "N" is 1,2,3 etc.  Other might prefer a 
slightly different label?

> and I here make the distinction
> between text blocks and "lists" that appear within a text block 
> (regardless of
> whether the items flowed or blocked itself), that is, I am excluding a
> discussion of such lists as a possible solution to the problem of 
> "excessive"
> levels of text blocks -- that's simply a non-solution to me.

We didn't get any further in the teleconf that discussing the hierarchy 
proper.   Discussion of lists, and much else is still to come.

>
> Last, I wanted to share that -- the defensive driver that I tend to be --
> software that I develop includes a Programming Instruction that 
> defines the
> structure to be used by a "contract editor" in the event that (a) new 
> blocks are
> inserted to the contract; or (b) the (indentation) level of an 
> existing block is
> changed; by an author or editor of the contract. In other words, this 
> critical
> information is not specifically within the "domain" of the information 
> within a
> contract, and this is precisely the sort of application that the 
> designers of
> SGML and XML had in mind for Programming Instructions. Now, this kind of
> information could also be called "metadata" either packaged with or 
> referenced
> by the contract -- fine, because that suggests that we could discuss 
> an XML
> element set to communicate a policy for the structure of the document, 
> including
> what "levels" of new markup is to receive captioning and numbering, 
> and what
> formatting is to be applied to the numbering of the inserted or 
> re-levelled text
> blocks. But, again, that would be metadata, not part of the document 
> proper.

I'm not sure i get what you are driving at here.  I've always used 
stylesheets to apply appropriate numbering to the clauses - you might 
call this autonumbering.  This way, if you edit the contract and move a 
clause or promote or demote it, it will automatically get the correct 
new number.

One of the questions we haven't discussed yet, is whether there is a 
need to be able to explicitly number each clause (ie if you don't want 
to leave this to your stylesheet).

cheers,

Jason