[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]
Powered by eList eXpress LLC