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: Core Components work plan


Hi All,

I sat in on some of the X12 CC discussions.  Much of the effort seemed to
focus on commonalities of information transmitted in a given message across
a set of industries.  That's interesting, but it does not yield the whole
story.  Let me explain.

To conduct business with its trading partners, a business needs a large
wealth of information.  Only part of that information need shows up in a
single transaction set - the part of the information which is dynamic in
nature.  The relatively static information is just as important to the
business process, but it has typically already been acquired and saved for
continuing use.  

Now it happens that information that is relatively static in one industry is
relatively dynamic in another industry.  So measuring commonality of
information actually exchanged in a given business document somewhat
understates the actual commonality of information needs. I suspect that a
'core component' should address the commonality of information needs (not
dynamic exchange needs), such that individual usage objects built upon the
object lilely act both to subset and superset the core component. 

I feel it is of prime importance to understand and map the relationships of
of the 'global' information sets (e.g., the 'party' set.  Given the global
information set, is is then appropriate to discern which portions of the
global set are not used at all in a given business, which are relatively
dynamic in nature, and what aspects of the business environment make this
so.

A second concern is that the X12 Transaction Sets were designed to provide
all the information needed to conduct a given transaction in that single
transaction set, without consideration of the nature or source of the
information.  So even information which is relatively static,
such as a business warehouse address, is accomodated in the tranaaction set,
even though in practice it is not often used, as that information may
already be stored in the recipient's database and linked to a warehouse
identifier.

In an internet environment, it makes more sense for a business to store its
own relatively static information in a well known location at its own
internet site, so that a trading partner who needs the information can
retrieve it as needed.  This leads to a different information model than the
model used to design an X12 Transaction Set. 

Cheers,
         Bob Miller  

=======================================================================
= This is ebxml-core, the general mailing list for the ebXML          =
= Core Components project team. The owner of this list is             =
= owner-ebxml-core@oasis-open.org                                     =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-core                                         =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-core myname@company.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