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: 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]