OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [MODIFICATION] Re: [regrep-cc-review] 8/21 Review Issue #3: Resolution


I'd like to modify the resolution for Question #2 - it should be:

Regarding Question #2 above: The Association will not be between
"OfficeAddress.Details" and "Address. Details" only - that is, there
will also be an Association between "OfficeAddress. Details" and
"Person. Details". This approach is necessary in order to provide the
proper Associations for the Assembly process.

Thanks,
Joe

Chiusano Joseph wrote:
> 
> Here is a rehash of this issue:
> 
> <Rehash>
> 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.
> 
> 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.
> </Rehash>
> 
> RESOLUTION:
> 
> Regarding Question #1 above: We will use an AssociationType of
> "DerivedFrom" between a "base" and "derived" ACC - that is, we will not
> specify whether the derivation involved extension or restriction (or
> both). Simplicity is the biggest factor here.
> 
> Regarding Question #2 above: The Association be between "OfficeAddress.
> Details" and "Address. Details" only - that is, there should not also be
> an Association between "OfficeAddress. Details" and "Person. Details".
> This approach simplifies maintenance (less Associations).
> 
> Thanks,
> Joe
> 
>   ------------------------------------------------------------------------
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.
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]