[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: ebXML Requirements - Some thoughts
All, First of all let me say that we had a good kick-off meeting for the ebXML initiative. I also realize that we have a very important task of specifying the requirements for this initiative. I want to share some general thoughts with you before we get too deep in the details of the specific requirements. This will build on my statements at our first meeting. The topics discussed below are meant to be a starting point. Neither the topics identified nor the discussion is intended to be exhaustive. In addition, topic order does not indicate importance in my mind. General Comment We heard a lot of comments about this being useful for the SMEs, however, I think that unless its also useful for the BEs (Big Enterprises) or LEs (Large Enterprises) it won't go very far. BEs have to deal with other BEs and SMEs simultaneously. Since the majority of BEs are already heavy EDI (X12 or EDIFACT) users, they have to be able to operate in that mode while they are trying to branch out and reach SMEs that may come up fresh using XML. I also think that we must try to avoid one of the problems that occurred in the early days of EDI. -- trading partner pairs and then industry groups can come up with their own set of standards for quick starts. It didn't take long to discover that no business, or industry group is an island, unto themselves. Incompatible trading partners started to bump into one another. We need to figure out a way to allow new things to be added quickly, but at the same time guard against the situation where we have two different ways of specifying the exact same thing. ebXML Semantics The ebXML semantics should at a minimum cover the semantics contained in X12 and EDIFACT. This is not to say that every X12 Transaction Set nor EDIFACT message be specified within ebXML -- only that one could if desired express the TS or message in ebXML. We may, however, have to be able to distinguish between X12 and EDIFACT semantics at the instance level. We may very well want to go beyond the semantic requirement of X12 and EDIFACT, however for our short term delivery we may want to use those as our baseline. ebXML tag names It think we should try to use one set of tags to cover both X12 and EDIFACT semantics rather that one for X12 orientation and one for EDIFACT. We will need to distinguish content (e.g. code values), however, this should be specified higher up in the exchange or referenced somehow. Internal/External Codes ebXML must be able to handle the internal and external codes used by both X12 and EDIFACT. The X12 dictionaries and the EDIFACT Directories should be the source for internal codes and identify the source of external code lists. Again we may want to go beyond X12, EDIFACT; however, we still have the potential compatibility issue. We want to make it easy to add/modify new codes/code sources, but we need rules so that it doesn't get out of hand. The EWG model works pretty well. Code Use We need to make certain that the codes and code lists usage in ebXML is the same as EDIFACT and X12. That is, we don't want a situation where a business application process must reconcile the differences between e.g. an EDIFACT Purchase Order feed and an ebXML Purchase Order feed. This does not mean the ebXML specifications should not go beyond X12 or EDIFACT Open Process You would want to have an open process in place whereby they can go to request addition/deletions/and Modifications to the semantic messages or code values. Suggest that it be under the UN. Also we do not want the process controlled by some interested group who could arbitrarily shut them off. Thus the UN process. Long haul Want to know that the process and standards will be there for a long time. Concerned that some group starts a process and since they really control it decide for business reasons to shut it down. Keeping the process under the UN umbrella is seen as the best way to guarantee the long haul. 50-100 years. Archives - A look into the future There is a need to be able to reconstruct the exact information content of a message received 20-30 years ago. It may be required for example in a legal court setting. Need to have standards versioned and historically understandable. Hope that this does not sound too long and vague. This a first attempt at our overall scope. Interested in your reaction. Dr. Donald D. Rudie 100 Locust Avenue Vice President Berkeley Heights, NJ 07922 Global Data Authority 908-665-6088 - Tel# rudied@dnb.com 908-665-6325 - Fax#
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC