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

["Rolly Chambers" <rlchambers@smithcurrie.com>]

Jim -

Please review the construction industry form contracts of the American
Institute of Architects (AIA), the Associated General Contracts (AGC), the
Engineers Joint Contract Documents Committee (EJCDC) for examples of
contract documents currently in widespread use that include an Article
structural element. I realize that you haven't used or don't use that term
in contract documents you work with, but others of us have used it and do
use it regularly.

I'm not hung up about whatever structural element names are used. I'll go
with whatever the group settles on, if we ever come to a consensus on the
subject. In my experience the structural terms being discussed (article,
section, part, clause, paragraph) are used loosely by many lawyers
(including me). To me this is one reason the "article v. clause v. part v.
section" issue isn't worth a lot of fuss.

I just want to point out that the proposed structural element names are
reasonable, reflect terms actually used in at least some "standard" contract
documents, and would probably be fairly intuitive to (and readily understood
by) most lawyers. Just my two cents.

Rolly Chambers

----- Original Message -----
From: "jkeane" <jik@jkeane.com>
To: <legalxml-econtracts@lists.oasis-open.org>
Sent: Wednesday, April 16, 2003 10:09 AM
Subject: RE: [legalxml-econtracts] RE: Proposal: One container per level in
the clause hierarchy (was Re: [legalxml-econtracts] Caption Numbers)


> If we go with article, is it optional? How will these structural elements
> work for container with meaning? How would you mark up the ADR section or
> paragraph using this approach?.
>
> Re use of article. I don't know of anyone who call the ADR section an an
> "article."
>
> James I. Keane
> JKeane.Law.Pro
> 20 Esworthy Terrace
> North Potomac MD 20878
> 301-948-4062 F: 301-947-1176 (N.B.: NEW FAX NUMBER)
> www.jkeane.com <http://www.jkeane.com>
>
> Co-Author and Annual Update Editor of Treatise: Litigation Support
Systems,
> An Attorney Guide 2nd
>
<http://www.westgroup.com/store/product.asp?product_id=16989703&catalog_name
> =wgstore>   Ed. (WestGroup, 1992, updated through 2002)
>
>
> -----Original Message-----
> From: Jason Harrop [mailto:jharrop@speedlegal.com]
> Sent: Wednesday, April 16, 2003 12:12 AM
> To: legalxml-econtracts@lists.oasis-open.org
> Subject: Re: [legalxml-econtracts] RE: Proposal: One container per level
> in the clause hierarchy (was Re: [legalxml-econtracts] Caption Numbers)
>
>
> John McClure wrote:
> > Jason. now that I'm understanding a little more of your approach, here's
a
> stab
> > at your markup applied to the 3 level structure I posted the other day.
>
>  >>From your note, it sounds like you want (holding aside the issue of
> Caption
>  > Numbers):
>  >
>  > <Contract>
>  >    <p>text for a para eg recital</p>
>  >    <Article>
>  >       <Title>Article Title</Title>
>  >       <p>text for article, or is this text for a para in the
article.</p>
>  >       <p>text for another para in the article.</p>
>  >       <Section>
>  >          <Title>SectionTitle</Title>
>  >          <p>text for section, or is this text for a para in the
> section.</p>
>  >          <p>text for another para in the section. </p>
>  >          <Paragraph>
>  >              <Title>Para Title</Title>
>  >              <p>text for para.</p>
>  >              <p>text for another para</p>
>  >          </Paragraph>
>  >       </Section>
>  >    </Article>
>  > </Contract>
>
> That looks right. At least from <Article> down.  The TC has not said
> anything about the front or back matter, ie your "<p>text for a para eg
> recital</p>" which precedes the <Article>.
>
> I think that we'll discover that it makes sense to put the clauses of
> the contract into a container, so at the highest level you might have:
>
> <Contract>
> <FrontMatter>
>
> [your "<p>text for a para eg recital</p>" would live in here]
>
> </FrontMatter>
> <Clauses>
>
> [Articles in here]
>
> </Clauses>
> <BackMatter>
> </BackMatter>
> </Contract>
>
> > As I
> > look at the markup, whether you call it <p> or <body> or whatever, I
don't
> see
> > how you overcome the problem with the paragraph at the top of the
> document,
> > prior to any clauses (or articles or sections) being introduced.
>
> If you look at a collection of written contracts, you'll see that the
> clauses are always highly structured, and I claim, can be properly
> modelled by the hierarchy that I have advocated.
>
> That is the only part of the contract the hierarchy is intended to apply
to.
>
> What we do with the rest is a separate problem, albeit one which can
> also leverage off the hierarchy (if a hierarchy is required, eg in the
> recitals).
>
> > If there is
> > formatting associated with this <p> tag, such as p {margin-top:1em},
then
> I am
> > concerned that it would affect the layout badly within the <Artlcle>
> element,
> > because it would place that content onto a different line, without fail.
>
> The comes back to the philosophical question about the relationship of
> this work to presentation.
>
> I know you disagree here, but my view is that styling is a separate
> concern to structural markup.
>
>
> > I just
> > don't see it working correctly if one wants the text for an Article, or
> Section,
> > or Paragraph, to be on the same line as the Title of the block, I am
sorry
> for
> > being dense about this, but it's not immediately clear how that would be
> done.
>
> For this, you have two perfectly sensible choices:
>
> 1.  transform your Title, so it appears on the same line as the text
>
> 2.  start with the title inline in the text in the first place, maybe
> using an element called something like <InlineHeading>, or just <bold>
>
> I don't see how this is a criticism of the hierarchy i have proposed.
> Is it a question about where a Title should be allowed?
>
> I haven't responded to the rest of your post, because it comes back to
> the philosophical question about presentation.
>
> cheers,
>
> Jason
>
>