RE: [legalxml-econtracts] Citation-related Reqs

["John McClure" <jmcclure@hypergrove.com>]

Thanks Peter. Unfortunately, it does cut across the M/H Model, in that there is
no need for lists, tables, paragraphs, or other formatting elements. There is
only the need for a <Block> element. Sure, there might be one or two more once
we identify positional patterns of LegalXML namespace elements necessary to
represent 95% of contract captions. We'll see.

I think it's important to propose *other namespace* elements to fulfill the
functions called for by the Clause Model requirements. It represents a finality
of standards specification that simply is not apparent with the MH model. A
standard that implements a few, transparent, elements is one that is surely more
easy to sell -- the XBRL dialect, based on 2 elements (<group> and <item>), is a
hit because it is not complicated. My concern is: when complete the MH model
duplicates much of what XHTML already provides. The manner of the MH model
affects us all by multiplying the process (time and energy) of creating a
standard by at least a factor.

In this regard, you state that "there is no direct equivalence between proposed
clause model elements and many of the XHTML elements you mention". This confuses
me because the requirements for the Clause Model does indeed name lists, tables,
and paragraphs as important items to be addressed either now or soon. You also
state that "XHTML does not provide the needed structure for the wide range of
intended uses. That is why we are developing a new clause model." I agree with
you, and that is the function of the <Block> element -- to provide that
structure in the presentation datastream where it REALLY counts during the
linking process.

My proposal is essentially just for a <Block> element and a lgl:names
attribute -- I am preparing now the proposal for the lgl:names attribute. I
believe that this combination meets our needs for (1) identifying the structure
of a contract encoded in the XML dialect chosen by the parties (2) identifying
semantic items of information in the contract. And both support external linking
to internal, presentation, content.

I envisage that our major activities when preparing the Technical Specification
are (1) to develop a set of citations and (2) to wrangle over the scope and
content of the data model relevant to our first set of "reserved names" that are
the content of the "lgl:names" attribute I'm proposing. I believe these two
activities would be far more valuable to the community than to wrangle over
elements that represent paragraphs, tables, and lists.

Taking a look at the charter, I also think my parsimonious model, taken together
with other requirements I am stating, is more consistent with our Mission
Statement while more clearly indicating our way forward. In fact, my proposal
neatly aligns with the deliverable listed following the Functional Requirements
document we're now about:

	B. The eContracts TC shall complete one or more data models
	meeting the requirements specified in this Charter.

The scope statement also identifies "support (for) the production of human
readable output documents" as a goal of our DTD or Schema. I anticipate that the
argument raised in favor of the MH model is that it provides this support,
whereas my parsimonious model does not. However, there is nothing preventing us
from providing that support for whatever dialect may be chosen by the parties
by providing *guidance* on the creation of *citable* human readable documents.

Finally, I think that my parsimonious model is more true to the self-imposed
chartered requirement for our group's activities:

	(ii). W3C and OASIS specifications, as well as, ISO or other
	appropriate standards shall be used.

My model more effectively uses, conforms with, and supports whatever W3C- and
OASIS- dialect that the parties may themselves elect, not to mention proprietary
dialects. The MH model on the other hand conforms with just DTDs, a
specification essentially deprecated by the XML Schema and RDF Schema Technical
Recommendations published beginning in May 2000.

-----Original Message-----
From: Peter Meyer [mailto:pmeyer@elkera.com.au]
Sent: Thursday, October 23, 2003 11:15 PM
To: Legalxml-Econtracts
Subject: RE: [legalxml-econtracts] Citation-related Reqs


Hi John,

I have been over your citation related requirements posting. It seems to me
that the issues you raise are all interesting and that there is much work to
be done on this area. I think we will need to focus on just how users will
create links in their documents and how we will avoid dependencies on
particular processing technologies. Personally, I think that most of your
stated conclusions are more design preferences rather than functional
requirements but that will need further discussion.

My immediate concern was to establish whether you are proposing anything
that would cut across the basic clause model development.

As far as I can see, there are only two points that might impact:

Conclusions #2, second and 3rd bullet points
The second point says that DTD content models should be declared as ANY. The
third says that everything is OK with XML Schema definitions.
Its an issue to determine how schema languages are to be supported. This may
be a relevant input into that decision.
For the moment, I believe we should complete the clause model proposal
without dealing with these particular requirements. It does not affect
development of the basic concept that is proposed in the Harrop/Meyer
proposal.

Conclusions #3
This seems to require us to use elements from the XHTML namespace. At least
at the structural markup level, I believe this is fundamentally inconsistent
with the clause model requirements. There is no direct equivalence between
proposed clause model elements and many of the XHTML elements you mention.
XHTML does not provide the needed structure for the wide range of intended
uses. That is why we are developing a new clause model.

Am I correct in assuming that there is no reason to not proceed to finalise
the Harrop/Meyer proposal?

Regards
Peter