[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] re: Agenda for 7/13 meeting
Folks, 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. John
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]