[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Comments on Initial Core Components Catalogue Ver 1.01 (Appendix A)
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"
Powered by eList eXpress LLC