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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: [Fwd: [regrep-cc-review] "Top-down" vs. "Bottom-up" Registration]


This is additional information regarding the recent Registry TC thread
w/subject "[Fwd: [CEFACT-ATG:672] [atg2] modularity discussion]". I
could not forward the URL from the CC Review archives, as only those
subscribed to the CC Review listserv would be able to see it.

I sent the e-mail below to the CC Review listserv last Friday; it
details a situation in which I believe it is imperative that a BCC
contain an Object Class upon registration (see reference to "Document.
Processing. Code" BCC), and one in which it would not be required (see
reference to "Country. Identifier" BCC).

[The remainder of this e-mail is for the CC Review folks]

Some additional information regarding the points below:

See "(1) CCTs AND THEIR METADATA ATTRIBUTES" in original e-mail:

I'm considering situations in which a BCC may be based on a Core
Component Type (CCT) (such as "Code. Type"), rather than on a restricted
CCT (which would be a Data Type). I believe it would be most efficient
in these situations to simply indicate within the BCC (using a Slot) the
CCT that applies (Code. Type, Identifier. Type, etc.). Then, if the BCC
is based upon a restricted CCT (a Data Type), there would be an
association from the BCC to that Data Type. Please let me know your
thoughts on this.

See "(2) NAMING DATA TYPES:" in original e-mail:

After further consideration, and after further reviewing the OAGI Core
Components work, I've decided against using freeform names for Data
Types. I believe that Data Types should have more structured names that
will end in the word "Type" - such as "Country. Code. Type". Please let
me know your thoughts on this.


-------- Original Message --------
Subject: [regrep-cc-review] "Top-down" vs. "Bottom-up" Registration
Date: Fri, 02 Jan 2004 14:20:34 -0500
From: "Chiusano Joseph" <chiusano_joseph@bah.com>
Organization: Booz Allen Hamilton
To: CCRev <regrep-cc-review@lists.oasis-open.org>

CC Review Team,

Happy New Year to all.

In going through some use cases involving the registration of Core
Components, I've realized that there needs to be 2 possible approaches
for registering Core Components:

- Top-down
- Bottom-up

The CCTS spec does not address this aspect (probably for a very valid

Consider registration of an Aggregate Core Component (ACC) and a Basic
Core Component (BCC) that is contained within the ACC. The "top-down"
approach involves registering the ACC then the BCC, while the
"bottom-up" approach involves (you guessed it) registering the BCC then
the ACC. Which approach is taken (or even required) depends on whether
or not a BCC can be registered without an Object Class in its Dictionary
Entry Name (i.e. without an ACC), or whether an Object Class is required
for the BCC to "stand on its own". That is, whether or not an Object
Class is "required" for a BCC to be registered.

More details to follow - please let me know what you think of the
concepts below.

For example, we will register the following entities:

- Document. Details (ACC)
- Document. Processing. Code (BCC)

By an Object Class being "requiring", we mean: given the Data Type that
the BCC is based on, does a Dictionary Entry Name that contains only a
Property Term and Representation Term provide enough semantic clarity to
sufficiently describe the BCC?

For example: A BCC whose Dictionary Entry Name is "Country. Identifier"
has a Dictionary Entry Name (I believe) that provides enough semantic
clarity to sufficiently describe the BCC, in the absence of an Object
Class. That is, the BCC "Country. Identifier" can be associated with a
Data Type named "International country codes" that lists all ISO country
codes from ISO 3166-1. Therefore, both the "top-down" and "bottom-up"
registration approaches can be used here - that is, the BCC can be
registered first (along with the Data Type), and then the ACC can be

But consider a BCC whose Dictionary Entry Name is "Processing. Code" -
the question remains, "what type of processing code? Document processing
code? Chemical processing code? Patient processing code?" So we can say
that the BCC Dictionary Entry Name is "Processing. Code" does NOT have a
Dictionary Entry Name that provides enough semantic clarity to
sufficiently describe the BCC, in the absence of an Object Class.

Furthermore, what Data Type would this BCC be associated with? Could
there be a Data Type that represents "processing codes"? This would
probably be too "generic" a subject for a Data Type.

However, a BCC whose Dictionary Entry Name is "Document. Processing.
Code" (i.e. contains an Object Class)  has a Dictionary Entry Name that
*does* provide enough semantic clarity to sufficiently describe the BCC.
That is, there may exist a set of "Master document processing codes"
that an organization uses that are represented as a Data Type named
(perhaps) "master document processing codes" that lists all the
organization-specific master document processing codes (Note: this Data
Type will be further restricted when a BBIE called
"PurchaseOrder_Document. Processing. Code" is created based on this

Therefore, only the "top-down" registration approache can be used here,
because the Object Class (which is a property of the ACC) needs to be
"known" when the BCC is registered, so that the full Dictionary Entry
Name for the BCC ("Document. Processing. Code") can be constructed. That
is, the ACC must be registered first, and then the BCC can be registered
(along with the Data Type).

In other news:


We will be moving the metadata attributes listed in the CCTS for Core
Component Types (CCTs) - i.e. code list ID, agency ID, etc. - to Data
Types. The primary reason for this is that from a modeling perspective,
I believe that the CCTS representation is not accurate. That is, it
lists a very "generic" Dictionary Entry Name of (for example) "Code.
Type" for a CCT, but very "specific" properties (such as code list ID,
etc.) that can only apply to an entity whose name is more specific then
"Code. Type". 

That is, trying to express the code list ID for something named "Code.
Type" is equivalent to going to a car dealership and telling them that
what you specifically want is a "car" (with no other description). The
CCTS team suggested that we work around this CCTS spec defect by
creating a set of  "empty entities" in the registry to represent each
CCT (Code. Type, Identifier. Type, etc.) with "empty properties" - but I
believe that we would be very remiss to create such a kludge in our
architecture. No disrespect whatsoever is meant to the CCTS team or any
of their members - just fulfilling my duty to express things in black
and white terms for the benefit of our initiative.


I'm starting to see that Data Types should have freeform names, as in
the examples above (e.g. "Master document processing codes") - it just
makes things a lot easier, and I don't see that it is necessary to
provide structured names for Data Types as we do for Core Components,
BIEs, etc. 

Does anyone see a strong need for us to use structured names for Data
Types? What specific purpose would they serve?


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

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