[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: http://www.legalxml.org/DocumentRepository/ProposedStandards/Clear/PS_10001/ PS_10001_2000_07_24.htm The URL will probably wrap and break. You can also get to it from a direct link at: http://www.legalxml.org/CourtFiling/ 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*, Characteristic*)> <!ELEMENT Name (Person | Entity | Thing)> <!ELEMENT Person (FullName, Salutation?, FirstName?, MiddleName?, LastName, Suffix?, Designation?, NameAlias*)> <!ELEMENT Entity (FullName, EntityAbbreviatedName?, EntityAcronym?, NameAlias*)> <!ELEMENT Thing (#PCDATA)> <!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, Todd ============================== 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. Other > parties, distinguished by the role they play, e.g., an Intermediate > Consignee or a Carrier, may be outside of the Trading Partners. Many years > 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 Party > - 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, etc > 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 doing > 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 and > accept commercial only use as a constraint, and > * if TRP works, it will be used in none "trade" contexts since people won't > 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]
Powered by eList eXpress LLC