10 messages in org.oasis-open.lists.legalxml-econtractsRE: [legalxml-econtracts] re: Agenda ...| From | Sent On | Attachments |
|---|---|---|
| Dr. Laurence Leff | Jul 8, 2004 7:25 pm | |
| John McClure | Jul 10, 2004 11:02 am | |
| Jason Harrop | Jul 12, 2004 5:26 pm | |
| John McClure | Jul 13, 2004 4:21 pm | |
| John McClure | Jul 13, 2004 8:27 pm | |
| Jason Harrop | Jul 13, 2004 11:26 pm | |
| John Messing | Jul 14, 2004 6:07 am | |
| John McClure | Jul 14, 2004 8:42 am | |
| Jason Harrop | Jul 15, 2004 12:17 am | |
| John McClure | Jul 19, 2004 8:22 am |
| Subject: | RE: [legalxml-econtracts] re: Agenda for 7/13 meeting | |
|---|---|---|
| From: | John Messing (jmes...@law-on-line.com) | |
| Date: | Jul 14, 2004 6:07:26 am | |
| List: | org.oasis-open.lists.legalxml-econtracts | |
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" <jhar...@speedlegal.com> Date: Tue, July 13, 2004 11:03 pm To: "'Legalxml-Econtracts'" <lega...@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.