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