RE: [legalxml-econtracts] Signature Areas

["John McClure" <jmcclure@hypergrove.com>]

Jason,
The text for "G" is in the <p> element, but the table for the signature stuff
would not be. The table *should* be outside of the <section> and <layout>
structure of the document.

I am troubled about a Signature block element -- it seems too presentational in
nature for my taste. I am more attracted to one or more inline elements, My
objective is to create XHTML markup that can be re-formatted into XSL-FO (for
conversion to PDF), so I think the key is to identify the text strings that are
to be used by that XSLT to create the FOs representing the "signature block" --
I think this is an important objective to have because it keeps us "honest" as
we create a "logical" markup language using a presentation-oriented markup
language as its foundation.

Some inline signature related elements coming to mind follow, which I'm sure can
be improved, but here goes:

	a. <signature-party> - holds the name of a party signing the document
	b. <signature-date> -- holds the date of the signature
	c. <signature-intro> -- holds text that introduces the signature area
	d. <signature> -- holds the image of the actual signature

Now, I assume and accept that there will be content in the XHTML file that is
irrelevant to the XSLT creating the FO/PDF for the contract. A table in the <p>
within the <section> would always by formatted as part of the contract. A table
outside of the <section> element would not be identity-copied, although it would
be accessed for its inline signature elements.

My view necessitates that preamble text (and postscript text) for the contract's
sections is to be so identified -- I proposed a generic <layout> element, but
it'd certainly be alright to use element names for each layout area, eg footnote
text, header text, footer text, and others as needed. This yields something
like:

	<instrument>
		<running-header/>
		<preamble/>
		<section/>
		<postscript/>
		<running-footer/>
	</instrument>

Thanks,
John

>-----Original Message-----
>From: Jason Harrop [mailto:jharrop@speedlegal.com]
>Sent: Tuesday, November 25, 2003 8:45 PM
>To: 'Legalxml-Econtracts'
>Subject: Re: [legalxml-econtracts] Signature Areas
>
>
>So John, for your XHTML model, that's a SignatureBlock element in <p>,
>or just a table element in <p>?
>
>Peter, i'd be interested in your views.
>
>thanks
>
>Jason
>
>
>
>
>John McClure wrote:
>> Hey Jason,
>> I thought youmight get a grin out of that... The answer has to be yes, the
>> author would need to create a <section> for that content. I owuld agree that
>> it's likely not a usual practice, but in order to be labelled "G",
>then yes it
>> must be a <section> as part of the doc outline. Note that doing so, the user
>> expects that the Signatures block would be listed in any generated table of
>> contents (navigation list) for the document, something that wouldn't
>be done if
>> the content was not located in a <section>.
>>
>>
>>>-----Original Message-----
>>>From: Jason Harrop [mailto:jharrop@speedlegal.com]
>>>Sent: Tuesday, November 25, 2003 5:52 PM
>>>To: 'Legalxml-Econtracts'
>>>Subject: Re: [legalxml-econtracts] Signature Areas
>>>
>>>
>>>Hi John
>>>
>>>Nice to see an example document :)
>>>
>>>Presumably you/Peter would encapsulate the signature blocks within item
>>>G, since it appears to be the authors intent that conceptually, they
>>>form part of the grammatical para in item G?
>>>
>>>thanks
>>>
>>>Jason
>>>
>>>
>>>
>>>
>>>John McClure wrote:
>>>
>>>>Here is a simple 3 page lease that captions the signature area of a contract
>>>>consistent with the numbering of its preceding clauses. This is not a common
>>>>practice, but I wanted to share that it does occur. My proposal to
>>>
>>>identify just
>>>
>>>>the specific signature text using an inline element, would not lead to the
>>>>concerns that arise from trying to markup a signature area when it
>>>
>>>occurs within
>>>
>>>>a clause.
>>>>
>>>>http://www.aa.psu.edu/stulife/housing/sample_lease.pdf
>>>>
>>>>
>>>>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_w
> orkgroup.php.
>
>>
>>
>
>
> 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_w
> orkgroup.php.
>
> 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_w
orkgroup.php.
>
>
>


--

Jason Harrop
CTO, SPEEDLEGAL
jharrop@speedlegal.com

Melbourne
Mob +61 (0)402 02 66 34
Tel +61 (0)3 9670 0141
Fax +61 (0)3 9670 0142
www.speedlegal.com

SmartPrecedent(R) software
The most intelligent way to create documents


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_w
orkgroup.php.