Re: Comments to Core components Analysis

[Martin Bryan <mtbryan@sgml.u-net.com>]

Henrik Reiche wrote:

> In general we would like to see every code entity accompanied with a
text-entity
> and both of them embedded in an aggregate entity (ex: Party Type,
containing
> 'Party Type Code' and 'Party Type Name'). Probably there will be an
endless
> discussion about using codes or names (word description of the code in
what ever
> language), and in our implementatios we concluded both is needed
(optional), as
> codes are procesable, words are readable). This was reported in the forms,
but
> is not reflected in the spreadsheet.

In trying to prepare the examples that I sent out on Sunday morning I found
it was necessary to define a Type definition for all core components, rather
than just those that were likely to be used as context-dependent abstract
elements. I also identified a number of other elements that needed to be
used "abstractly" in different circumstances (e.g. names) and so extended
the range of abstract elements accordingly.
>
> I completely agree with Martin in his thoughts about "abstract" and
> "context-specific" core components (Note from 17/1), using inheritance. In
this
> case it would be possible in one context to use only codes, or in another
> context to use only names, but inheritance from the "abstract" would
ensure the
> "correct" use of the "context-specific" component, ensuring reusability
(no date
> without a type and format).
>
> In his note, Martin further says  "AbstractParty, which have synonyms such
as
> Buyer, Seller, Client and Insurer". As we discussed in Tokyo, I still
think we
> have to separate "BUSINESS ROLE" from "PARTY". Business is performed
between
> ROLES (Buyer, Seller, Insurer), and it is the role, that defines the
context. A
> role is then performed by a PARTY, but a party can perform other
activities
> (driving, arrange, advise).

It has always been my intention that the Business Role described in the
Business Plan will be one of the key context drivers. I would contend that
this role is what is recorded within the message in place of the abstract
element so that we properly record which parts of the message apply to which
business partner. The fact that a party plays many different roles within a
business transaction does not mean that the specific parts of a single
message do not apply to single party. What context-driven names do is to
highlight which parts of the message are linked to which parts of the
partner roles (e.g. delivery party address may be the same as the invoice
delivery address, but both need to be stated in specific parts of the
message, and the difference between the two needs to be clearly defined).

Martin Bryan

Martin Bryan