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


Subject: 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.

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.

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 .... 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.

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.

John McClure
Hypergrove Engineering



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