[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?
Nothing like short emails. Thank goodness we're not dealing with mathematical equations ! -D > -----Original Message----- > From: William J. Kammerer [mailto:firstname.lastname@example.org] > Sent: Monday, April 23, 2001 11:29 AM > To: ebXML Core > 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.htm > l 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" > > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: email@example.com >
Powered by eList eXpress LLC