[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Core component catalogue V1.0 comments
As part of an analysis of the Party definition while preparing a comment on the ebXML Core Component work for the CEN/ISSS Defining and Managing Semantics and Datatypes working group I came to a similar conclusion to Mike Conroy about the need to split out information relevant to people (who I have chosen to call Persons) from those relevant to enterprises (which I have chosen to call Organizations). Being simple-minded, and having to aim my document at managers, I did not formally model my definitions, but instead defined a simple classification hierarchy for the definition of parties, as follows: Party Person FamilyName GivenName Initial MiddleName Initial Title Gender Nationality BirthDate TaxIdentifier Organization Name IncorporationDate TaxIdentifier PostalAddress Building Name Identifier Suite Floor MailDeliveryPoint Street Lot Block District Town State Region County PostCode Country POBox UnstructuredLine Location Identifier Type Description Position WhenAvailable Date Time ZoneOffset Sequence CommunicationDetails Environment WhenAvailable Date Time ZoneOffset Mode SecurityInformation Number CountryCode AreaCode SubscriberNumber Extension Account Identifier Name Nickname Servicer Type InterestRate Charge Owner Country Currency CardExpiry Date Language Code Purpose FreeTextDescription Hopefully you will find this as easier to understand than the spreadsheet or formal models used to date to describe the relationships between the information that needs to be recorded about a party. It should also be noted that such a tree represents a hierarchy that can easily be recorded in XML. Martin Bryan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC