[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Just what is a Core Component? Or, when is stealing wrong?
Last Friday I examined the "means of transport.details" aggregate in the Core Component catalog, Initial CC Structure v1-03.xls, sent out in http://lists.ebxml.org/archives/ebxml-core/200104/msg00125.html by James Whittle on 12 Apr 2001. I noted the aggregate's similarity to the UN/EDIFACT composite C222 Transport Identification, and was pleading that the CC catalog refer to the EDIFACT composite on which an aggregate is based. This isn't a matter of accusing anyone of plagiarism - after all, copying what already works is a healthy phenomenon - but it's hard to discern patterns and notice omissions if the original source is not referenced. I mistakenly noted that C222's 1131/3055 pair (for describing the authority responsible for identifying the truck or vessel) was not propagated to the "means of transport.details" aggregate. I was confused by "means of transport.identification.code" which was identified as a "Basic" component - I didn't realize that "code.type," whence it was derived, was a complex component in its own right (i.e., an "aggregate"). The "code.type" component indeed simulates all aspects of an identifier qualified by the 1131/3055 pair - i.e., it includes the agency (code list.agency.identifier) and the coded list (code list.identifier). So, now, it's perfectly clear C222 was used to "discover" the "means of transport.details" aggregate. Likewise, the "amount.type" aggregate at Line 26 looks like a subset of UN/EDIFACT composite C516 MONETARY AMOUNT, used in the MOA segment, at http://www.unece.org/trade/untdid/d01a/trsd/trsdmoa.htm, lacking the (infrequently used) Currency type code qualifier and Status description code. It's also missing an analog to the EDIFACT D.E. 5025 Monetary amount type code qualifier which would describe what the amount is all about: e.g., Tax, Charge or Instalment amount. If that was done on purpose, was it because it was felt that the type or purpose would be able to be divined from some "context"? In UN/EDIFACT, the MOA segment is commonly used to augment a TAX Duty/tax/fee details segment - the latter describes the tax, the tax rate and the basis (e.g., weight or quantity), with the MOA giving the actual tax amount. In this case, the "context" would be clear - it's the tax amount since the MOA was further describing the TAX. Or it could be the amount subject to the tax described in the TAX segment, requiring calculations based on the tax rate - an altogether different notion (requiring explicit qualification using D.E. 5025 in EDIFACT). So, if "context" really will say what kind of monetary amount is being described with the "amount.type" aggregate, then why not rely on context to say what kind of location is being described in the "location.details" aggregate? The "location.identification.code" is derived from "code.type," and hence has enough, in combination with "location.description.text," to simulate everything in UN/EDIFACT composite C517 LOCATION IDENTIFICATION, at http://www.unece.org/trade/untdid/d01a/trcd/trcdc517.htm. But there's also a "location.type.code," which makes the aggregate behave more like the LOC segment - which contains the C517 - where D.E. 3227 Location function code qualifier serves the purpose of the location type. In any event, we should explicitly acknowledge the LOC/C517 heritage in the definition of the "location.details" aggregate so I don't have to go hunting it down. Similar borrowings from UN/EDIFACT are seen at Line 30 with the "quantity.type" aggregate, which is just a rehash of composite C186 - without any acknowledgement in the CC spreadsheet, at http://www.unece.org/trade/untdid/d01a/trcd/trcdc186.htm. UN/EDIFACT all but mandates use of UN/ECE Rec. 20, at http://www.unece.org/cefact/rec/rec20en.htm, for the Measurement unit code, where both X12's D.E. 355 or the preferred recommended codes can be used. These seem to be adequate for all or most cases, so the superfluous quantity unit code list.identifier and the quantity unit code list agency. identifier can be discarded from the definition of "quantity.type." As an aside, why are these 1131/3055 look-alikes defined as "string" data types, while in other cases derivations are made from "code.type"? By the way, don't ask me why the UN/EDIFACT D.E. 6060 Quantity is defined as an alphanumeric character string as opposed to a numeric (which can accommodate "real" or "decimal" numbers). I could go on and on about wholesale theft from UN/EDIFACT. And say, doesn't Line 102's "account.details" aggregate look suspiciously like the FII (Financial institution information) segment, or even the CPT (Account identification) segment? The CPT seems to only be used in accounting type messages - the bane of Todd Boyle! My point isn't that there's anything wrong with stealing. But the catalog at a minimum should acknowledge the source for each entry. And if all we're going to do is steal EDIFACT composites and segments for building core components, why not dispense with the (manually built) catalog altogether, and just build general rules for going from EDIFACT to an automatically generated CC catalog? If this is what we agree should go into core components, then perhaps - since even the UN/CEFACT EWG has its shorts in a bunch over modeling - we should model UN/EDIFACT and build both the EDI syntax and the ebXML XML syntax from the intermediate UML. This would save valuable time and effort. Keep in mind, though, the resulting core components would be just as difficult to piece together and use as the EDIFACT equivalents. But since everything will be couched in terms of data models, XML and schema, it will be billed as a great success warranting press coverage the world over. It will be our little secret that the CC catalog is nothing but the EDI wolf in sheep's clothing. 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