RE: [legalxml-econtracts] re: Agenda for 7/13 meeting

[John Messing <jmessing@law-on-line.com>]

With regard to signatures only, what is the nature, intent and effect of
the signatures? Are they to represent a manual signature of a
contractant, provide a tamper-evident seal, authenticate the signer, or
what?

> -------- Original Message --------
> Subject: Re: [legalxml-econtracts] re: Agenda for 7/13 meeting
> From: "Jason Harrop" <jharrop@speedlegal.com>
> Date: Tue, July 13, 2004 11:03 pm
> To: "'Legalxml-Econtracts'" <legalxml-econtracts@lists.oasis-open.org>
> 
> Please see comments inline.
> 
> John McClure wrote:
> > 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. 
> 
> I said tables, signatures, headers/footers, and clause numbering needs 
> to be done.
> 
> I didn't say "preambles, front matter and back matter"
> 
> There isn't a lot of work in tables, signatures, headers/footers, and 
> clause numbering, and work in those areas needs to be done whether one 
> does it my way or yours:
> 
> - tables, i think we all agree XHTML <table> should be used.  But, the 
> TC needs to provide guidance as to how to specify borders, shading etc. 
> ie should a CSS dependency be introduced?
> 
> - signatures: this can be treated as a standalone piece.  Whether we do 
> it your way or some other way, the work needs to be done.  And to do the 
> work, the TC should first say "here are examples of the signatures we'd 
> like to be able to represent, and here are our expectations about the 
> effort an author should go to to input them"
> 
> - headers/footers: the TC needs to provide guidance as to whether these 
> are in the XML or the stylesheet; the rest is easy.
> 
> - clause numbering: this needs to be thought through a bit.  one issue 
> is in exchange between applications, when is an application allowed to 
> renumber?  This is tied in to cross references.
> 
> > 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. 
> 
> I think that whether one uses your adjustments to XHTML2, or the ones 
> Peter and I tend to favour, the same issues need to be addressed.  It is 
> the solution which looks different.
> 
> It is the issues the TC needs to provide guidance on; it is from that 
> guidance that the best solution will flow.
> 
> And, in my opinion, could yield an
> > implicitly superior product.
> 
> > 
> > For tables, I recommended using XHTML <table> elements.
> 
> 	(Yes, but questions remain as to how to do borders, shading)
> 
> > For signatures, I recommended one container <area> element.
> 
> 	(Introducing a new element called <area> is one of a variety of 
> possible models)
> 
> > For parties, I recommended identifying them in an associated RDF file.
> 
> 	(This is using a sledgehammmer to crack a wallnut.  It is imposing 
> considerable expense in terms of tools and training, when a far simpler 
> solution is possible)
> 
> > For dates, I recommended placing all dates into an associated RDF file.
> 
> 	(Out of scope of structural)
> 
> > For footers and headers, I recommended for each, an <area> element.
> 
> 	(TC needs to provide guidance as to whether these are in the document 
> or in the stylesheet)
> 
> > For front/back matter, I recommended for each item a container <div>.
> 
> 	(That is one approach.  The one Peter and I will suggest uses named 
> containers.  These could be mapped to <div> for a plain vanilla XHTML 
> document)
> 
> > For clause numbering, I thought we agreed <nr> contains just plain text.
> > For captioned tables/images, I recommended container <area> elements.
> 
> 	(Not sure that this addition is necessary)
> 
> > 
> > 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 
> 
> Not too many differences when expressed at this level...
> 
> (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.
> 
> This we probably disagree on, but the semantic question is exactly what 
> isn't structural, so its out of scope.
> 
> I think its pretty clear that the 2 approaches to the high level 
> containers ought to be compared, and the TC can choose the one it likes.
> 
> That will be much easier if you can stay quiet about the orthogonal 
> issues discussed in this email (headers/footers, areas, signatures, 
> tables) for a little while, and raise them at the appropriate point in 
> the process.
> 
> Jason
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_workgroup.php.