[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] Citation-related Reqs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]