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: RE: [regrep-cc-review] [ADDITIONAL THOUGHT]Re: [regrep-cc-review] ASCCs/ASBIEs Revisited


> 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.

> So we could potentially have many ASCCs in a registry derived from the
> "Address. Details" ACC.


> 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.
- 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
- 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
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??

> 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!). Having all that, you can classify the BIEs (RegistryObjects).
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.


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