Namespaces -- how many?

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

Zoran,
This moment my report recommends two namespaces - <legal:> and <layout:>. So
this is a good opportunity to create legal namespaces more in tune with your
thinking. To me, it does seem that the 10 types of legal instrument suggested in
the report  -- agreement, declaration, demand, etc. -- could each have a
namespace primarily to easily define context-sensitive terms,. For instance,
"instrument:Date" would be the reference date for the instrument; an
"agreement:Date" would be the date of the complete execution of an agreement;
and a contract:Date is the date of the formation of a contractual relationship
(which may be _extended_ by subsequent agreements) between the parties.

The alternative and conventional technique -- create one large namespace that
corresponds to the organization defining the namespace, and then throw
everything into it -- ultimately may be short-sighted as greater complexity is
included within its scope over time. This path can lead to pretty clumsy
@property names.

I'm now comfortable with the 3-part structure (legal:recitals, legal:body, and
legal:signature) designated for a <legal:instrument>. Within the language of the
contract, a string that represents the contract date (such as defined above) can
be placed in an element whose @property attribute has the value
"contract:Date" -- of course, only if so agreed by the parties to the contract.
[This is how I see the parties marking up their agreed-upon semantics about the
agreement -- as @property attribute values. External parties, or parties not in
agreement, would of course markup their own semantics about an agreement in a
file separate from the agreement. ]

But I'm definitely not comfortable with the property names now defined for use
within the <legal:signature> element. For instance, I settled upon
legal:Signer1Name, but I was REALLY more interested in "signer:FirstPartyName"
but had some doubts whether this approach would be acceptable to TC members.
Maybe I was wrong on this? My first draft had signer:SignatureLine, signer:Name,
signer:Date, signer:Location, signer:Title, and signer:Role, with
signer:FirstPartyXXX, signer:SecondPartyXXX, and signer:ThirdPartyXXX names
defined for each one.

I had a similar result with references. I started out with "ref:Section" for
instance, but ended up with "legal:SectionReference" because I didn't know
whether multiple namespaces would be acceptable to TC members who are resistant
to XML namespaces in general, or to members resistant to communicating semantics
in the prefix for a namespace, which a purist would say is a "should not"
intention of the XML Namespaces specification. Oh well.

BTW, the XHTML 2.0 spec has a new element called <separator/> that is used
instead of the old <hr/> (horizontal rule) element, but now with a twist -- by
using the @property attribute, it can be defined as a "page break" which can be
inserted anywhere within the text of the instrument. An EMPTY element such as
this is the markup technique used by the Transcripts TC for their documents.

Thanks for the helpful thoughts -- they'll work into the next draft.
John



>-----Original Message-----
>From: Zoran Milosevic [mailto:zoran@dstc.edu.au]
>Sent: Monday, July 26, 2004 7:49 PM
>To: 'John McClure'; Legalxml-Econtracts
>Cc: Jason Harrop
>Subject: RE: [legalxml-econtracts] Minority Report (in eContracts
>Markup), Part 2
>
>
>John,
>
>I am glad to see that you have started introducing <legal: ...> as a name
>space for the concepts that reflect key concepts of our e-contracts
>standard. This suggests to me that we are starting defining concepts that
>represent the 'semantics' of contracts - which is what we should be doing.
>
>By 'semantics' I cover here:
>
>1. The meaning of structural aspects of contract - that distinguish contract
>(and other legal documents) from other documents (note that so far we have
>use the word 'semantics' for other things re contracts - which may have been
>a bit unfortunate choice - as there is a meaning if something is a subclause
>of a clause etc).
>
>2. The 'semantic markup' - for simple type of information such as date,
>parties etc. It may be that some of these belong to 1., but as far as the
>overall contract document is concerned, this is not that important - I think
>we separated this to facilitate our work
>
>3. The 'semantic markup' - for more complex type of information such as the
>expression of obligations, events etc.
>
>I think we need to analyse and select key concepts from both proposals that
>have been discussed on this list and start agreeing which of the concepts
>are important for us - from the legal perspective. Let's step a bit back
>from tools capabilities, other standards that can be of relevance (XHTML,
>RDF, RelaxNG, vertical standards, XForms etc) and agree on the MODEL for
>these legal concepts. Maybe we can start with asking questions such as
>'would lawyers, courts etc consider this to be an important element'. For
>example, would any legal professional decide that page breaks are important
>for the meaning of contract (and I don't know the answer to it). We have a
>number of people with legal background here and I am sure they would be
>critical to answer some of these semantic questions.
>
>I suggest that we go through the process of selecting all these important
>concepts one by one and including them under the <legal ...> name space as
>you started. In other words let's start building a model for these concepts
>(I'd be happy to start using UML class diagram as it had well defined
>semantics). In doing this I feel we could start adding suitable terms that
>were identified in the XHTML standard, but for the moment they would be
>under our <legal ...> name space. This approach will force us to focus what
>is important and as I said in my previous email, the closer correspondence
>with XHTML would be only a bonus - allowing relative straightforward
>mapping.
>
>If we do this, we can then test this model through various use cases. Well,
>we may find a need for some pragmatic solutions which may not be part of a
>core semantic model. From my experience of being involved in other
>standards, it may be useful to think in terms of mandatory requirements (ie
>the core semantics) and some optional requirements (ie nice but not
>critical).
>
>What to other people think about this - can we start process of agreeing on
>a core model for contracts?
>
>Zoran
>
>
>
>
>> -----Original Message-----
>> From: John McClure [mailto:jmcclure@hypergrove.com]
>> Sent: Monday, 26 July 2004 5:08 PM
>> To: Legalxml-Econtracts
>> Cc: Jason Harrop
>> Subject: [legalxml-econtracts] Minority Report (in eContracts Markup),
>> Part 2
>>
>> Folks,
>> Attached is the next part of what I guess is now called the Minority
>> Report. I
>> expect one more swipe (sometime next week), then I am done with it. The
>> changes
>> to earlier-published Part 1 sections, are appropriately highlighted. I'll
>> do the
>> same when I publish the final version.
>>
>> All comments are welcomed ! Remember, the report is tested for display
>> using
>> Mozilla, not IE.
>> Regards,
>> John
>>
>> Jason.
>> The document you commented upon is NOT the minority report.
>>
>> >-----Original Message-----
>> >From: Jason Harrop [mailto:jharrop@speedlegal.com]
>> >Sent: Saturday, July 24, 2004 11:32 PM
>> >To: Legalxml-Econtracts
>> >Subject: Re: [legalxml-econtracts] Revised SC Report (in eContracts
>> >Markup), Part 1
>> >
>> >
>> >Hi John
>> >
>> >Here are some more detailed comments on your minority report.
>> >
>> >As i ask in the comments, could you please clarify whether we can expect
>> >more, including for example, the introduction of <area>, and a DTD?
>> >
>> >cheers,
>> >
>> >Jason
>> >
>> >
>> >
>> >John McClure wrote:
>> >> Attached is
>> >> (1) a new version of the report, marked-up using the structural
>> elements and
>> >> coding techniques that I am proposing
>> >> (2) the CSS stylesheet and
>> >> (3) a PDF rendition.
>> >>
>> >> Beware, IE users, the XHTML file will NOT display in IE because of
>> >its currently
>> >> lame support for CSS styling of XML.... one must either use Mozilla,
>> >or be happy
>> >> with the PDF.
>> >>
>> >> I am not planning to update the Word version sent earlier. Materially,
>> I have
>> >> modified statement 1.4 because there was a serious error there;
>> >nothing material
>> >> has changed except 1.4.
>> >> Thanks,
>> >> John