OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [legalxml-econtracts] Data Consortium Contract Schema Requirements


Hi Sergio,
I am hoping that the "basic" eContract spec encompasses deliveries of and
payments for any type of goods -- I have identified 5 types (Goods, Goodwill,
LegalInstrument, Premises, and Service) -- and that it includes supporting terms
fundamental to each of the five types. Landlord is a basic term in real estate,
sure, but initially I had Lessor and Lessee -- but changed it to Landlord and
Tenant because they are friendlier terms (easier for a user to find them in a
list, and intuitively know what they mean). Then I changed Tenant to Renter so
that the same term can be paired with an Owner of Goods in an Equipment Rental
Contract for instance in addition to a real estate setting, without loss of
meaning.

I agree that, once we're armed with a basic foundation, elements from other,
more specific, namespaces can be incorporated into instances of eContracts. I
would be very surprised if the eContract namespace ever included elements for,
say, the components of Operating Expenses for commercial office buildings
normally allocated to tenants... that's the job of the Data Consortium's
namespace for instance, but it IS the job of the eContracts namespace to be able
to reference those non-eContracts elements in instance documents (which I think
is done handily using the "nameRef" information item).

I had to chuckle reading your note -- the first release of the Data Consortium
vocabulary DOES abstract all roles (via <Role xsi:type=''>) as a single element,
but I found much to my dismay that noone liked such a generic approach, so I've
backed off that model to one that is more explicit. The downside of course is
that many more elements need be defined in the eContracts spec, and questions
arise about how big the "starter" set of elements should be.

Thanks for your comments; they are good reminders to us all to keep the size of
this beast under control.
John


>-----Original Message-----
>From: Sergio Maldonado [mailto:sergio@smaldonado.com]
>Sent: Monday, February 03, 2003 3:38 PM
>To: John McClure; 'Legalxml-Econtracts'
>Subject: RE: [legalxml-econtracts] Data Consortium Contract Schema
>Requirements
>
>
>I find it very interesting, although it certainly has a higher reliance on
>structure and real-estate specifics than I would have expected.
>
>An important issue that comes to my mind at this point is the convenience of
>contract type-specific "objects" such as that "landlord" type, if I may call
>it like that. It seems clear to me that, despite helping simplify things for
>the given type of contract (eg real estate), it would require the schema to
>remain continuously open to further element or type definitions (originating
>from different contract types).
>
>But of course, defining a single vocabulary that avoids such "objects" would
>require the abstraction of all possible relationships between any number of
>parties to a contract instead (such as those linking the Renter, Payer and
>Payee, which could, for instance, be eventually used to describe the
>relationships between the parties to a Bill of Exchange in International
>Trade contracts). Quite a challenge.
>
>A "cascading" model though, with specific industries being able to define
>their own contract type-specific sub-vocabularies inheriting from a solid
>eContracts spec, could be the efficient way forward.
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC