Re: Comments on Initial Core Components Catalogue Ver 1.01 (Appendix A)

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

Thanks to Paula Heilig for attempting to clear up the distinction
between "Required" and a minimum occurrence of 1 or more.
Unfortunately, I don't quite grasp the subtle difference.

The Requirement indicator is a holdover from EDI standards, where
(generally) no minimum occurrence is indicated for segments, but only
the maximum;  a separate indicator marks the segment as Mandatory (or
Required) vs. Optional.  If the minimum no. of occurrences (minOccurs in
xsd schema) is specified as 1, it stands to reason that the element is
*REQUIRED* to appear. Also see Table 1. Occurrence Constraints for
Elements and Attributes in XML Schema Part 0: Primer.  This unnecessary
bit of information neither appears in UML diagrams nor in DTDs or
schemas.

It might be nice to highlight or boldface - or even color in bright
chartreuse - the Cardinality (or "MinMaxConstraints" in the heading)
column when the Embedded Entity has a minimum occurrence of 1 or more.
But as a minimalist, I still recommend that the Required column be
dumped - it's redundant and only adds clutter.

And in the further interest of minimalism, I had also recommended that
we lose the date.adjustment.count in time.details. We are - after all -
talking about *core* components common to all business sectors, and
hardly any should need to be distracted with this bit of information.
Though I wouldn't presume to doubt that there is indeed some airline
regulation requiring the date adjustment factor, those in that
predicament - within the Travel biz - can "extend" the time core
component with the extra baggage perhaps unneeded by the rest of the
world.

My objection is not because I have to carry any extra data in XML
document instances - I perfectly well realize the date.adjustment.count
is optional - oops!!! make that: has a cardinality of 0..1!!  But
another complaint about EDI - especially UN/EDIFACT - is all the
optionality:  people look at the standard messages and just feel
hopeless and helpless when presented with all the options.  Unless using
a message implementation guideline (MIG), nothing is constrained and you
have no idea where to start since you have so many choices.  It's kind
of like when I'm in the parking lot at Meijer - I get an anxiety attack
just at the thought of so much choice that I turnaround and go to a
smaller store.

By discarding (little used) choices, we eliminate complexity for the
vast bulk of people who will want to implement ebXML.  Let's give
RosettaNet their due: they were ruthless in this regard - i.e., barring
choice wherever possible - by uniformly identifying a partner with a
D-U-N-S number, a product with a UCC/EAN GTIN Global Trade Item Number,
and classifying a product with a UN/SPSC.  And yes, there's only one way
to specify Dates and Times (ISO 8601) - and they seem to get along fine
without a date.adjustment.count.

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"