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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: Re: Trading Partner or Party - What's in a name

This is my first post to this list.  Just as an introduction, I'm a lawyer,
with some technical background, but no formal technical degree.  I organize
Legal XML (http://www.legalxml.org/)

I've seen a lot of groups struggle with names.  The following is a legal
perspective on names and an example of how we solved the name problem in a
recent Court Filing specification.  (You may also be interested in this
specification, because it has an "Envelope" that is conceptually very
similar, although not as sophisticated, to your TR&P specification (posted
to this list 8/10/2000.)  See:


The URL will probably wrap and break.  You can also get to it from a direct
link at:


From a legal perspective, only a "person" and a "thing" can be sued (thus,
these are the only things that have relevant names) (note, a "noun" is a
person, place, or thing -- places have names, but they aren't really
important in this context).  A "person" can be a natural person (human
being) or a legal entity (corporation, partnership, limited liability
company, trust, etc.).  A "thing" (such as a boat or a parcel of land) can
sometimes be sued "in rem" if, for instance, there is no person associated
with it or if the associated person (the owner) is not subject to the
jurisdiction of the court (i.e., is outside of it).

This is a helpful perspective because it nicely categorizes what can and
needs to be named.

In the Court Filing specification, we abstracted "person" to <Actor>.
<Actor>s can have <Role>s.  So, in this thread, you name a series of
<Actor>s each of which has a role (e.g., Intermediate Consignee).  The same
<Actor> can have multiple <Role>s.  <Role>s from one <Actor> can be
associated with another <Actor> using <RoleWith>.

An <Actor> also has a name.

However, a <Name> can be of a "person" (natural or legal) or a "thing" each
of which needs a different content model.  The following are some of the
relevant DTD declarations.

<!ELEMENT Actor (Title?, Name?, Address*, Telephone*, Email*, Group*,
PersonDescription*, (PersonIdentifier | BarMembershipInformation)*, Role*,

<!ELEMENT Name (Person | Entity | Thing)>

<!ELEMENT Person (FullName, Salutation?, FirstName?, MiddleName?, LastName,
Suffix?, Designation?, NameAlias*)>

<!ELEMENT Entity (FullName, EntityAbbreviatedName?, EntityAcronym?,


<!ELEMENT Role (RoleName,RoleWith*)>

We have argued over whether <LastName> ought to be optional (?).  <FullName>
is there because sometimes you might get a "full name" as a text string and
you might not want to parse it, but need a place to store it.  Also, you
might not know how to categorize a name (i.e., you might not know whether it
was first or last).  The argument for requiring <LastName> is that sort
programs often sort on <LastName>, so regardless of what you get, something
ought to be in <LastName>.  I'm not sure this is a great argument, but
that's what we decided.

The <Actor> abstraction means your application needs to do a little more
work (and/or your standard has to specify acceptable <Actor> values), but
what you get is flexibility and a powerful way to express just about any
actor, name, and relationship.

I hope this helps,

Winchel 'Todd' Vincent, III
Attorney and Technical Researcher
Project Director, E-CT-Filing Project
Georgia State University
J. Mack Robinson College of Business
and College of Law
Phone: (404) 651-4297
Fax: (425) 955-1526
Email: winchel@mindspring.com
Web: http://e-ct-file.gsu.edu/
Legal XML: http://www.legalxml.org/

----- Original Message -----
From: <sfuger@AIAG.ORG>
To: <david.burdett@commerceone.com>; <ebxml-transport@lists.ebxml.org>
Sent: Monday, August 21, 2000 12:05 PM
Subject: RE: Trading Partner or Party - What's in a name

> In EDI, the Trading Partners are the parties exchanging the document.
> parties, distinguished by the role they play, e.g., an Intermediate
> Consignee or a Carrier, may be outside of the Trading Partners.  Many
> ago, we struggled with these terms in X12.
> Any way, that's my two cents.
> Regards,
> Sally Fuger
> -----Original Message-----
> From: David Burdett [mailto:david.burdett@commerceone.com]
> Sent: Monday, August 21, 2000 11:31 AM
> To: ebXML Transport (E-mail)
> Subject: Trading Partner or Party - What's in a name
> Foks
> We have two names for essentially the same thing - Trading Partner and
> - does it matter?
> My personal view is that there should be one, but which?
> For my 2c here are my views on the pros and cons of each:
> For Trading Partner:
> * Well known term used widely within EDI to identify a company, business,
> etc involved in trade
> * Implies that commerce or business is involved
> * Used by IBM in their Trading Partner Agreement
> For Party:
> * also a well known term used identify one of the companies, businesses,
> involved in trade
> * does not necessarily imply that Trade is involved.
> IMO, I prefer Party to Trading Partner since a lot of the work we are
> in ebXML, e.g. TRP and Core Components, can be used in a non commercial
> context and to imply that it could be used only in a commercial context by
> using *might* limit its use. On the other hand:
> * the "b" in ebXML stands for "business" so maybe we should be explicit
> accept commercial only use as a constraint, and
> * if TRP works, it will be used in none "trade" contexts since people
> care they'll just want to take advantage of it anyway.
> Thoughts?
> David
> Product Management, CommerceOne
> 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC