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" <>
> Date: Tue, July 13, 2004 11:03 pm
> To: "'Legalxml-Econtracts'" <>
>
> 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.
