[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] re: Agenda for 7/13 meeting
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]