RE: Just what is a Core Component? Or, when is stealing wrong?

["Welsh, David" <David.Welsh@nordstrom.com>]

Nothing like short emails.
Thank goodness we're not dealing with mathematical equations !

-D


> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> 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: ebxml-core-request@lists.ebxml.org
>