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


Subject: [legalxml-econtracts] RE: Basic Contract Structure - Sections


Marc,
I not only agree that Paragraphs should have SubParts , but also Clauses should
have SubParts  -- that's a good name for those parts of a clause or a paragraph
that occur on a separate page from its main part. For clauses as grammatical
entities, I think that might be defined by a separate namespace, so no name
collision occurs. About the ambiguity  issue , it is  proposed that a Contract
may be composed of Clauses, Sections or Paragraphs; the specific structure of
Section-Clause-Paragraph does NOT lock anyone into using that structure when
composing a Contract  -- sandwiching the Clause element occurs only within a
Section element.

I've also added a Caption element and a Pagination element to the template, the
latter of which indicates text ordering and what page the content occurs on. The
ordering information is important when clauses are technically encoded as a
"bag" rather than an "ordered set" of text blocks; the page information is
useful to citation mechanisms, and the stylesheet reference anchors both these
pagination and document assembly parameters to specific software URIs. I suppose
there can be multiple Pagination elements each referencing a different
Stylesheet, and the value of a Stylesheet element defaults to the stylesheet
associated with ancestor elements, up to and including the root of the
datastream. Ditto for the PageNumber element, whose ultimate default is "1"
which corresponds to a "webpage".... a Stylesheet element NOT in the context of
a Pagination element is to be used to format the text in a "standalone" mode,
particularly useful to "clause library" operations. The Stylesheet element can
contain either CSS or XSL content (or reference) depending on the value of the
conventional "type" attribute. Last point is that there is no difference between
the contents of a Clause or Paragraph element, and that I propose that we adopt
the xhtml elements and structure defined for the <p> element as allowable
element content within our Paragraph,Clause, and Caption elements -- this would
include the <table> and list elements, and the various simple formatting
elements such as <b>, <i> and <u>.
John

<Contract>
    <Clause>
          <Caption/>
          <Pagination>
               <NextTextItem/>
               <PageNumber/>
               <Stylesheet/>
          </Pagination>
          <Paragraph>
               <Caption/>
               <Pagination/>
               <SubParagraph>
                    <Caption/>
                    <Pagination/>
                    <SubPart>
                       <Caption/>
                       <Pagination/>
                    </SubPart>
                </SubParagraph>
                <SubPart/>
          </Paragraph>
          <SubClause>
                <Paragraph/>
          </SubClause>
    </Clause>
    <Paragraph/>
    <Section>
        <Clause/>
        <Paragraph/>
        <SubSection>
          <Clause/>
          <Paragraph/>
        </SubSection>
    </Section>
</Contract>

-----Original Message-----
From: Marc Lauritsen [mailto:marc@capstonepractice.com]
Sent: Friday, January 24, 2003 4:07 PM
To: "LEXML"@capstonepractice.com"@mindspring.com; "@killy.mspring.net;
jmcclure@hypergrove.com
Subject: Re: Basic Contract Structure - Sections


"Clause" is one of those terms in document drafting (and document automation)
with considerable structural ambiguity vis-a-via sections and paragraphs.  So it
would seem unfortunate to adopt a structure that locks it into a position
between the two.
For instance, often people refer to sub-parts of a paragraph (or even of a
sentence) as a clause.



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


Powered by eList eXpress LLC