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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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

Subject: Re: Comments to Core components Analysis

Henrik Reiche wrote:

> In general we would like to see every code entity accompanied with a
> and both of them embedded in an aggregate entity (ex: Party Type,
> 'Party Type Code' and 'Party Type Name'). Probably there will be an
> 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,
> 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
> 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
> Buyer, Seller, Client and Insurer". As we discussed in Tokyo, I still
think we
> have to separate "BUSINESS ROLE" from "PARTY". Business is performed
> 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
> (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

[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