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: RE: [legalxml-econtracts] re: Agenda for 7/13 meeting

Though it is the summer, I am concerned that time (6 weeks) continues to slip by
without much progress being made by the subcommittee; that Jason reports that
there is yet a very significant body of work needed to be finished; and that
Peter's memo suggests that over the near-term, he's unable to participate at the
level he'd like.

Their view is that much needs to be done - tables, signatures, parties, dates,
headers, footers, preambles, front matter and back matter, and even clause
numbering. That is alot !!! IF AND ONLY IF one is aiming to re-craft XHTML
rather than to adopt XHTML 2.0 as much as technically possible. My point is
this: given their methodology then Jason is plainly correct that more thought
about a contract schema is required but, by adjusting the methodology, the
result could be entirely different. And, in my opinion, could yield an
implicitly superior product.

For tables, I recommended using XHTML <table> elements.
For signatures, I recommended one container <area> element.
For parties, I recommended identifying them in an associated RDF file.
For dates, I recommended placing all dates into an associated RDF file.
For footers and headers, I recommended for each, an <area> element.
For front/back matter, I recommended for each item a container <div>.
For clause numbering, I thought we agreed <nr> contains just plain text.
For captioned tables/images, I recommended container <area> elements.

So, my recommendation to Jason and Peter was this: (1) add a few new elements to
XHTML, i.e., 3 or 4 new elements (2) subtract a few old elements from XHTML (3)
impose constraints on the use of retained XHTML elements (4) use the XHTML
'class' attribute to identify the type of use for the element and (5) place all
'semantic' information about the contract, eg parties and dates, into an
associated (linked) RDF file that has a decidedly Dublin Core orientation.

An example of the power of this simple approach is this. XHTML allows multiple
<h> elements (heading elements) in a file.... which ONE is the correct title of
the contract? In my formulation, the answer is "look in the RDF file, in the
Dublin Core <Title> element" which is where the user (or software application)
is to place it.... As for their formulation, I wait patiently for an answer.

I also do recall that the subcommitteee was tasked over 5 months ago with
drafting a letter to the W3C to explore points of difficulty when adopting XHTML
2.0 as the basis of our standard. I submitted a draft of such letter to the
subcommittee in late February -- but it was tabled as premature at that time --
with hardly a word about it since. I do still support such a letter, believing
that the XHTML 2.0 group could be an important partner during the marketing
phase of our standard. However, if the intention is to craft a standard that
does not treat XHTML 2.0 as absolutely essential to legal XML documents, then I
fear such an opportunity to effectively advertise our specification likely won't
present itself again. That means, I most fear, that the standard would be
infrequently used, meaning it's no standard at all, meaning all of our time has
been terribly wasted.


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