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


Subject: RE: [legalxml-econtracts] Thinking about information models


I agree that pursuing "simultaneous parallel representations" opens the door to the question about which one "rules".... the intractability of that question however seems predicated on the notion that given text content is being represented in multiple schemas within the contract at the same time -- that is, the text is being duplicated first in one schema, and then in another. That approach is not what I believe is the proper way to solve our problems however.
 
Multiple schemas are accommodated very easily using a notation I developed (the Named Value Notation) with the Data Consortium .... which annotates elements with a "names" attribute whose type is NMTOKENS. *Each* of the tokens in this attribute identifies a node in an arbitrary information model whose text content is that of the annotated element's content. One then extracts the XML implied by the values of this "names" attribute, and from there extracts the elements that are relevant to the task at-hand (often an interface to an existing database). This notation works for any markup -- be it a standard W3C dialect (HTML, SVG); an OASIS dialect (Open Office, DocBook, UBL); a widely deployed proprietary dialect (MS Word 11); or a vertical industry dialect (Data Consortium).
 
An example is worth a thousand words. Attached is a lease contract that I pulled from FindLaw.com, and have marked up using the NVN.... The zip file also contains a stylesheet I wrote to convert annotated elements to conventional XML elements... The result of its application against the marked-up lease is in the file extract.xml. Please note the multiple children of the <rdf:Description> element. [I still have a few to-dos on this stylesheet (e.g., strip off the indexing suffix on an element's name and insert an rdf:ID), and I certainly welcome any comments about or contributions to this effort.]
 
Anyway, my answer to Jamie's question -- which representation of a contract is the definitive instantiation -- is that it is the formatted representation, that with which each party agrees, that is definitive. My view is unconcerned with the logical models populated by the contract's markup; and it correlates with my belief that it's perilous to ignore presentation issues (not to mention the problem I've said time and again caused by needing to link to XSL output -- now THAT's intractable!).
John McClure
 
 -----Original Message-----
From: James Bryce Clark [mailto:jbc@lawyer.com]
Sent: Wednesday, January 29, 2003 10:37 AM
To: legalxml-econtracts@lists.oasis-open.org
Subject: Re: [legalxml-econtracts] Thinking about information models

    Hello all.  Dave's comment points up a fundamental issue in our space. 
    As Rolly said, theoretically one can dismiss the physical model as a trivial problem and rely on transforms.  In fact you can view any of the layers Dave describes (below) as a trivial production from another one.  In theory.
    But in real life transforms are nontrivial.  In software, roundtrip transforms today -- XMI and the like, and managed code generators generally -- are not always as reliable as we might hope.  
    As practicing lawyers, we see analogous problems daily:
        -- multi-language written contracts with which-one-is-definitive issues; 
        -- B2B software that executes on business object models that prove  woefully nonisomorphic to the modeled reality;  
        -- content taxonomies that by reason of logical flaws overlook or mischaracterize important data;
and so on.
    In advising clients I insist on knowing which representation of a contract is the definitive instantiation.   Always.  None of this "heh, the OO representation is just as good", unless the object model is unambiguous and is the designated tiebreaker artifact -- because I get paid to ship certainty (or at least an expert assessment of its availability).
    So I am chary about simultaneous parallel representations without a clear provision for resolving inter-schema conflicts.  I am enthusiastic about Dave's view, but for that reason think it needs to be approached with caution.

Best regards    Jamie

At 12:23 AM 1/28/2003 -0800, Dave Marvit wrote:
It seems to me that the lens used to look at a contract determines which information models are most significant. * * *
1. A physical model document * * *
2. A structural model document * * *..
3. An obligation model document * * * in terms of commitments * * *
4. A parameterized model * * *
* * *

~ James Bryce Clark
~ 1 310 293 6739   jbc@lawyer.com
~ Chair, US ABA Business Law E-Commerce Subcommittee 
~ This message is not legal advice or a binding signature.  Feel free to ask me why.

Attachment: jan29.zip
Description: Zip compressed data



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


Powered by eList eXpress LLC