[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: ebXML core components diagrammed,or Whassup with all that derivation???
Many thanks to Mike Conroy for the UML diagram of the Core Components Catalog. I'm certainly no fan of UML diagrams, but this one was useful for picking out potential pitfalls in the catalog. A lack of balance - or busy-ness - in the diagram beckons us to investigate further. My eye is drawn to the big empty box entitled "identification.details" - like Rome, it has all roads leading to it. For some reason, that sets off warning bells. First of all, the identification.details aggregate depends on the code.details aggregate, which is extremely EDIFACT'ish looking. Of course, I love the 1131/3055 pair, but basing practically everything on such a structure is overdoing too much of a good thing - which I would say even if this were tired old EDI. Too much freedom is sometimes a bad idea. I think deriving many of the core components from identification.details gives leeway where none is needed. For example, the currency aggregate is derived from identification.details, in turn derived from code.details, presumably to allow the use of currency codes other than ISO 4217:1995 - Codes for the Representation of Currencies and Funds, at http://www.bsi-global.com/iso4217currency. Even if there were other code lists for currency, their use would be a special exception which wouldn't justify making the basic entity for currency carry so much baggage; a new currency object could be devised in that case. Even UN/EDIFACT makes do with ISO 4217 exclusively for denoting currencies. And there's no need to distinguish between the numeric and the alpha codes of ISO 4217 with a qualifier, as the recipient can tell the difference. If the intent were to signify what the currency is used for (e.g., Reference currency vs. Target currency), then that is certainly not clear from the matrix. The same thing attends the "country" aggregates, further complicated by there being multiple "countries" - account.country within account.details and country within postal address.details - both derived from identification.details. If they do the same thing, they should be derived from a common simple core component restricted to codes from ISO 3166-1:1997 - Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes, at http://www.din.de/gremien/nas/nabd/iso3166ma/index.html. There's no ambiguity between the 2 and 3 alpha country codes, or the numeric code of ISO 3166-1, hence no need for the baggage of the code list.identifier or the code list.agency.identifier. The country core component should just be a basic identifier, whose values are understood to be enumerated by ISO 3166-1. Assuming that party.nationality within party.details is also supposed to be an ISO 3166-1 country code, why not use a common base core component intended to designate countries? Then you wouldn't need three different "countries" all derived from the more abstract identification.details. Additionally, I realize that basing such components on identification.details drags along text.details, which might be useful for holding a natural language description of the ISO 3166-1 country code; but in actuality, that would be little used - a readable description is a crutch unneeded by "real" B2B interoperability. Though we're talking about party nationality, which could always be based ISO 3166-1, I think boats (you can tell I wasn't in the Navy) also have "nationality" designated with yet some other type of code, like a Lloyd's or Maritime Administration flag code. Still other applications might require the FIPS 10-4 country code, at http://www.odci.gov/cia/publications/factbook/docs/app-f.html. These are much less used (i.e., industry or government specific), and don't necessarily warrant support in the base core components, though particular sectors could derive their own to support these lists. William J. Kammerer FORESIGHT Corp. 4950 Blazer Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "accelerating time-to-trade"
Powered by eList eXpress LLC