Please see comments below marked <JMC>.
Diego Ballvé wrote:
>
> Joe,
>
> > Regarding CCTS spec p.12, example: Another way to view the "Address.
> > Details" ACC is as an abstract class which cannot be instantiated, but
> > which can be used to derive sub-classes. More specifically, "Address.
> > Details" would never appear in an XML document, but "Person. Residence.
> > Address" (for which "Residence" can be considered a sub-class derived
> > from "Address. Details") would appear.
>
> Nice way to see it. I agree with all but the fact that an ACC cannot be
> instantiated at all. If you assemble a form, the form itself can be
> viewed as an ACC, composed by ASCCs and BCCs.
<JMC>
Both our perspectives here are superceded by Mark Crawford's
clarification earlier today: "CCs (BCC, ACC, ASCC) will NEVER be used to
create an instance document. Only BIEs."
</JMC>
>
> > So we could potentially have many ASCCs in a registry derived from the
> > "Address. Details" ACC.
>
> Definitely.
>
> > It appears that the transition from ACC to ABIE occurs when business
> > context is added, and that business context is one of the 8 predefined
> > context categories (Business Process, Product Classification, etc.).
> >
> > It appears that the transition from ACC to ASCC occurs when business
> > context is added, but that business context is NOT one of the 8
> > predefined context categories. The same holds true for the transition
> > from ABIE to ASBIE - except that an ASBIE already incorporates one of
> > the 8 predefined context categories (by virtue of the fact that we are
> > starting with an ABIE).
>
> Agree on both.
>
> > I think we can represent ASCCs (created from ACCs) and ASBIEs (created
> > from ABIEs) with registry associations,
>
> I was voting for this approach but I have some doubts now.
> - First, Association is a RegistryObject but not a RegistryEntry. So you
> loose status and version control capabilities from RIM.
<JMC>
True - but I'm not sure what that is undesirable - i.e. why an
Association should be that "heavyweight". Taking the RegistryEntry
attributes one-by-one, and considering them in light of Associations:
expiration:
- Is there value in having an expirationDate for an Association?
majorVersion:
- Is there value in having multiple versions of an Association? To
me, it seems that either an Association exists, or it doesn't.
minorVersion:
- See "majorVersion"
stability:
- Relates to content; do Associations really have "content"?
userVersion
- See "majorVersion"
</JMC>
> - Second, since you don't have an ExtrinsicObject you can't set your own
> objectType attribute (ASCC/ASBIE in this case, although you can set
> associationType).
<JMC>
I think your last point regarding associationType is 100% correct - we
could have an associationType of (for example) "Derives From".
</JMC>
> - Third, in the attached document you've made the following note:
> "*Note that the relationship between the "Person. Details" ACC and the
> "Residence" ASCC can also be represented with a registry association.
> So there are really 2 associations here."
>
> How are you seeing this 2 Associations??? Like this?
> Person. Details ACC (Contains) Residence ASCC (Extends) Address. Details
<JMC>
Exactly. I should have stated that in the document - will update.
</JMC>
> But since an Association needs a source and a target, Residence ASCC
> must be a RegistryObject. would we have an Association as source/target
> of another??
<JMC>
Exactly. Residence ASCC would be a RegistryObject, with an Association
to the "Address. Details" ACC, and another Association to the "Person.
Details" ACC (I'm not being specific about the Association direction
here - just talking high-level).
If we feel the registry is becoming "heavy" with all these
RegistryObjects, there is an alternative for the Residence ASCC - for
example, it could be represented with a Slot on the "Address. Details"
ACC RegistryObject. However, this approach hits a brick wall when we
have to "join" the Residence ACC (represented as a Slot on the "Address.
Details" ACC RegistryObject) to the "Person. Details" ACC. With multiple
Slots on the "Address. Details" ACC - each representing an ASCC - how
would we indicate which Slot is participating in the Association? So
there may be no better way than representing these ACCs and ASCC as
RegistryObjects.
</JMC>
>
> > while the transition from ACCs
> > to ABIEs can be represented by classifications (per the 8 context
> > categories). The path from ACC to ASBIE will therefore use both
> > associations and classifications - the order of which depends on whether
> > the path was:
> >
> > ACC --> ABIE (classification) --> ASBIE (association)
> >
> > OR
> >
> > ACC --> ASCC (association) --> ASBIE (classification)
>
> Classification can (only) be made based on a ClassificationScheme.
> I see it so that if you have 8 predefined context categories, then you
> have 8 ClassificationSchemes (containing all the posible classification
> nodes!).
<JMC>
Yes.
</JMC>
Having all that, you can classify the BIEs (RegistryObjects).
<JMC>
Yes.
</JMC>
> But you still need 2 RegistryObjects (1 CC and 1 BIE) and 1 Association
> between them.
>
> Said that, I didn't get the point for the 2 paths.
<JMC>
What, you mean you can't read my mind? ;) I should have been clearer:
I believe there are 4 possible "transitions" involving ACCs, ASCCs,
ABIEs, and ASBIEs:
(1) ACC --> ABIE
(2) ABIE --> ASBIE
(3) ACC --> ASCC
(4) ASCC --> ASBIE
That is, a Registry user should be able to "convert" an ACC to an ABIE
(case #1), an ABIE to an ASBIE (case #2), etc.
I obtained this list by considering all 12 possibilities (assuming X -->
X was not valid - such as ACC --> ACC), and negating the ones that did
not make sense. For example, the following did not make sense:
ASCC --> ABIE
ASBIE --> ACC
etc.
Having said that, the path from an ACC (the most generic entity) to an
ASBIE (the least generic entity) could be gotten two ways:
Join (1) and (2): ACC --> ABIE --> ASBIE
Join (3) and (4): ACC --> ASCC --> ASBIE
Lastly, we can use classification and association as follows:
ACC --> ABIE (classification) --> ASBIE (association)
ACC --> ASCC (association) --> ASBIE (classification)
Please let me know if you think this makes sense.
</JMC>
> Diego
>
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
