[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: core components analysis
More comments re: the CC Analysis Document; see http://lists.ebxml.org/archives/ebxml-core/200012/msg00009.html. On Wednesday, I misread the table for the Language Aggregate. I can now see that it has its own definition at line 107, which includes a base component, Language Code (Identifier), which refers to ISO 639-1988. Though Martin Bryan thinks ISO 639 is incomplete, and instead advocates IETF RFC 1736, I think the deficiencies of the language code list have been addressed by ISO 639-2 which is an extension of the ISO 639-1 code set, and takes care of every oddball and obsolete language out there; see http://lcweb.loc.gov/standards/iso639-2/englangn.html. I think the Library of Congress as the RA for ISO 639-2, and a language authority in its own right, trumps the IANA. The Dublin Core makes allowance for using either technique, though. Line 20: Party Identity aggregate. Is Identification Code an enumerated list of values identifying the authority responsible for assigning the Identifier? If so, the discussions ongoing in TR&P under the thread "PartyId and Context" re: identifier authorities (e.g., UN/EDIFACT D.E. 0007, ASC X12 D.E. I05 and ISO 6523) are relevant here. See http://lists.ebxml.org/archives/ebxml-transport/200012/msg00131.html. Line 31: Address aggregate. Are Building/House Name, Building/House number, Street name, Lot identifier, Apt number, Mailstop, Area name, Sub area name, Floor number, Block number, Address number and P.O. Box Number really all necessary for any business domain? Especially travel? Except for specific applications like mortgage loan applications, and real estate appraisal and taxation, why would all this stuff be needed broken out for an address? I would think these fields would only be carried along as readable data for the postman. For most business purposes, X12's N3 and EDIFACT's NAD are adequate by simply providing repetitions of an Address line. Breaking out street addresses into every conceivable constituent is a bit like decomposing telephone numbers unnecessarily, considering that they're probably going to be read by humans. Which brings us to: Line 55: Communication Point aggregate. Is breaking out the telephone number into Telephone Country Code, Telephone Area Code, Telephone Local Code, and Telephone Ext really necessary, esp. when ITU-T Rec. E.123, Notation for national and international telephone numbers, exists for formatting them? See some comments on telephone numbers at http://lists.ebxml.org/archives/ebxml-architecture/200004/msg00044.html, which also talks about dates and times and brings us to: Line 79: the Date/time aggregate. All of the base components Date, Time (and their respective formats) and Time zone offset can be accommodated in one field by conforming to the ISO 8601 Date and Time Format; see http://www.iso.ch/markete/8601.pdf.. XML Schema Part 2: Datatypes already support many ISO 8601 Date and Time Formats natively. Line 48: The County name component in the Address aggregate is overkill in U.S. addresses. And if needed, it's most certainly desired to be in a format that's machine processable, as in mortgage loan processing or tax applications. X12 readily accommodates passing the County name in either readable or coded format, the latter for U.S. locations as a FIPS-55 county code. Line 119: What's the difference between Unit of measure component in the Product/service aggregate, and Unit type code in the Quantity and Dimensions/Measurements aggregate? The latter should be named Unit of Measure, and should be the kind of stuff (meters, feet, liters, etc.) in X12 D.E. 355 or UN/ECE Recommendation No. 20 - Codes for Units of Measure Used in International Trade, at http://www.unece.org/cefact/rec/rec20en.htm. Since the Brief Description accompanying the Unit of measure component in the Product/service aggregate reads "Same part number could be for a coil or cut length of a product," and coils and cut lengths are not UOMs, this component should be renamed. Just because X12 D.E. 355 (Unit or Basis for Measurement Code) commingles measurement units and "coils" and "bobbins" and "Hogsheads," doesn't mean we should! But one nice thing X12 provides, absent from UN/EDIFACT, is some means to apply exponents to UOMs so you don't have to really invent a code for Terabecquerel, when you can use composite element C001 - Composite Unit of Measure - to say Becquerel raised to the 12th power (R2:12). Can we make the ebXML CC Unit of Measure an aggregate to accommodate exponents? William J. Kammerer FORESIGHT Corp. 4950 Blazer Memorial Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "Commerce for a New World"
Powered by eList eXpress LLC