Re: TechArch V0.5 Comments

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Bob Miller raised some objections regarding sections 2.1.9 Defining
Objects (Data Elements) and 2.2.0 Modeling data Elements from Business
Objects, especially the part (2.2.0.d) where "Each Data Element
(repository object) in a business process must be identified and
classified until it is atomic.  This process will be conducted in a
Repository."

2.2.0.j shows a telephone number broken into its "atomic" components,
the PREFIX "(604)" and the PHONE "717-1100".  Bob quite rightly demurs
at "prohibiting the definition of a data element that represents a
‘complete’ phone number represented as a single text string value."

And I object to the ridiculous degree of platonism required in 2.2.0.

If I had to think of every chunk o' data that I receive in the course of
a day in terms of its atomic structure, my head would explode!  Let the
people who spend their entire careers immersed in telephone numbers
decide how these things are to be parsed and what they mean, namely the
ITU folks. The rest of us can just use phone numbers in the familiar old
format, with or without parentheses, spaces and geegaws, and muddle
through like we always have with EDI.  Phone numbers normally are
expected to conform to ITU-T Rec. E.123, Notation for national and
international telephone numbers. This *standard* addresses specification
of country codes, trunks, subscriber numbers, and optional spaces,
dashes and parentheses, e.g, +44 1223 334676, +1 512 305 0280, or the
sample in the document: (604) 717-1100.

The same goes with dates and times: there's no need to bust the date out
into month, day or year;  if it's an ISO 8601 date (or even an EDIFACT
date format qualified by D.E. 2379  - Date/time/period format
qualifier), then there's a *standard* for interpreting the string as
components.  There's no need for help from some "repository".

Other examples abound, where we treat a number or string as a unit, even
though the cognoscenti know otherwise.  What are we going to do next?  -
Take UCC/EAN product codes and break them into the company prefix, item
code and check digit?  In EDI, as in real life, these things are treated
as atomic units.   For those that really need to dissect and parse to
extract the etymology, they can refer to the appropriate standards.

There are some, few, real life situations where we break apart into
smaller components, such as a full name into the Christian or given
name, middle name and surname.  And if the individual names are that
important to the task at hand, they'll already be separated out.  As an
example, the N1 segment in X12 adequately handles complete names, but
the NM1 segment is sometimes needed to hold the individual pieces of a
name, along with monikers and any suffix.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
(614) 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"