[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue #3: P.12 Example in the Registy
Team, Here is the next issue from the 8/21 Registry TC review. It relates to the CCTS spec p.12 example: In the example, it is assumed that the "Address. Details" ACC is not directly joined to the "Person. Details" ACC; rather, there is an "intermediary term" ("Residence" or "OfficialAddress") that "linls" the 2 ACCs together. The CCTS spec calls these Association Core Components (ASCCs). We are not planning to store ASCCs as Core Components as defined in the CCTS spec; rather, we are planning to represent them as Associations. Having said that: There are multiple ways to construct this example in the registry. Here is the approach we have been referencing in our discussions - please review it *carefully* and *pick it apart* step by step, word by word. It's critical that we have agreement on this approach. I will cite clarifications that we've already had in the recent past from the CCTS Team as necessary. *** Please note that if there is not sufficient enough feedback on this issue by 9/5/03, we will proceed in our Technical Note in the manner described below. *** We will consider "Address. Details" a "base" ACC, from which other ACCs (e.g. "ResidenceAddress. Details") as "derived" ACCs. Consider the following steps (I've inserted some questions along the way): 1. Create BCCs for "Address. Details" ACC (Street, etc.) 2. Create the "Address. Details" ACC - use Associations between each BCC and the ACC 3. Create BCCs for "Person. Details" ACC (Name, etc.) 4. Create the "Person. Details" ACC - use Associations between each BCC and the ACC (Now we create "derived" ACCs from "Address. Details") 5. Create a new BCC called "MailStop" - it will be used for the "OfficeAddress. Details" ACC below 6. Create the "OfficeAddress. Details" ACC - use the "Address. Details" ACC as a basis, and *extend or restrict it*; use Associations between the "OfficeAddress. Details" ACC and the "Address. Details" ACC QUESTION: Do we need 2 new Association Types here - "ExtendedFrom" and "RestrictedFrom"? Or just simply one Association Type named "DerivedFrom?" If so, should we handle this the same as W3C Schema? That is, an extension would contain only the additional BCCs, and a restriction would contain the BCCs from the "base" ACC that are being carried over. QUESTION: Should the Association be between "OfficeAddress. Details" and "Address. Details" only? Or, should there also be an Association between "OfficeAddress. Details" and "Person. Details", so that an "assembler" does not have to route through "Address. Details" to assemble together "Person. Details" and "OfficeAddress. Details"? Now, suppose that a change takes place to the "Address. Details" ACC - a BCC's name is changed. If an implementation allows, that change can propagate to all derived ACCs. That's all... Joe
begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@bah.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]