[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Core Component Analysis - SWIFT's Comments
Jacques Littré, in the "SWIFT Comments on the 'Core Component Aggregate Entities' ebXML CC Document," advocates getting rid of EDIFACT-like qualifiers. Instead of hiding the semantics of a <Date/Time> aggregate in a "PurposeCode," Jacques reasonably suggests using the InformationEntityUseName as the tag name itself, eliminating the PurposeCode describing the particular kind of date: <Party> ... <BirthDate> <Date>20010101</Date> <Time>102300</Time> .......... </BirthDate> <DeathDate> <Date>20800202</Date> <Time>102300</Time> .......... </DeathDate> ........... </Party As an aside, I'm a little confused by the ellipses in <BirthDate> and <DeathDate>, since there's very little more that one could add to these elements: date and time are pretty much all you need to describe a BirthDate. But this does inspire some observations, motivated by Martin Bryan's "The need for process-based semantic sets," at http://www.sgml.u-net.com/semantics.htm. Since the example goes to the trouble of enveloping subordinate <Date> and <Time> elements, there's no need for the "Date" suffix in <BirthDate>, which unnecessarily restricts its extension to further describe attending facts to a "Birth" event: Location, Hospital, Attending Physician, Weight, etc., etc. The "context," if you will (pardon the overloaded use of the word), is set by the Name of the enclosing tag; all subordinate tags can be assumed to pertain to a Birth: <Birth> <Date>1922-10-16</Date> <Location> <CityName>Cincinnati</CityName> <CountryCode>US</CountryCode> <CountrySubEntityName>Ohio</CountrySubEntityName> </Location> .......... </Birth> A <Date> element, based on the XML Schema "date" type, is understood to be expressed in the ISO 8601 extended date format Likewise, it's understood that the <CountryCode> basic core component is expressed as an ISO 3166 2 alpha country code. The <CountrySubEntityName> semantics could be subsumed into <CountryCode> if we were to agree that the latter could be represented by an ISO 3166-2:1998 country (and optional subdivision) code; thus <CountryCode>US-OH</CountryCode> would unambiguously identify Ohio, the home of Warren G. Harding. Since everything enveloped within <Birth> describes the birth event, there's no need for a redundant "Birth" prefix on any of the enclosed element tag names. And now the ellipses make sense, because there's clearly more information that we could see pertaining to a Birth event. The same stuff found within <Birth> would also find a place in describing Death events. The above is a nice collection of data useful for most business applications which require birth date and location information. Rarely would the birth time be recorded, especially for an adult, but the <Date> could easily be replaced by: <DateAndTime>1922-10-16T10:40-0500</DateAndTime> But if Birth Date (and Time, for whatever reason) were the only desired facts pertaining to the Birth, the component instance should be able to be abbreviated as: <BirthDateAndTime>1922-10-16T10:40-0500</BirthDateAndTime> Or more usefully, in business applications, as: <BirthDate>1922-10-16</BirthDate> 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