ebXML Registry: Deviations from CCTS

["Chiusano Joseph" <chiusano_joseph@bah.com>]

All,

I recently compiled a list of our deviations from the CCTS spec (i.e.
those places where we needed to make adjustments in order to efficiently
represent Core Components in our ebXML Registry architecture). I thought
I'd forward this list, so that it is clear to everyone where we are
going. Any comments, please send them to the CC Review listserv (or to
me, for those not on the CC Review listserv).

There's really nothing new here - these all resulted from our CCTS
review/analysis in summer 2003. Please let me know if you think I've
missed any.

If you feel that any of these deviations are not just, please provide
detailed, complete information as to why.

Thanks!
Joe

</Deviations>
(1) ASCCs and ASBIEs will not be represented as entities as described in
the CCTS; rather, they will be represented as Registry associations;

(2) BCCs will not be required to have Object Classes (but some will need
them); this allows us to register a BCC named "Country. Identifier" and
reuse it within multiple ACCs. However, a BCC named "Processing. Code"
does not provide enough semantic clarity to stand on its own; so it will
require an Object Class (such as "Document. Processing. Code"). This
determination will need to be made by the registering user.

(3) Addition of Object Class Qualifiers will not always cause an ACC to
become an ABIE. That is, addition of an Object Class Qualifier of
"Residence" for an ACC called "Address. Details" does not result in an
ABIE; rather, "Residence_Address. Details" will still be considered an
ACC because "Residence" does not fall under any of the 8 context
categories.

(4) Core Component Types will not be represented in the registry as they
are in the CCTS. That is, CCTS lists properties for CCTs (such as
codeListID for CCT Code. Type) that do not belong at that level - that
is, they belong at a "higher" level (such as Data Type). The reason for
this treatment is that one cannot determine the code list ID, agency ID,
etc. for a CCT that is simply named "Code. Type" - i.e. there has to be
more specific information in the Dictionary Entry Name, such as
"Country_Code. Type". So, we will "transfer" the CCT properties to Data
Types and not represent CCTs as RegistryObjects.

(5) There will be more than the 8 context categories required to create
BBIEs/ABIEs. The additional context categories required can be left to
the user.

(6) Properties will not be represented in the registry as defined in the
CCTS - this approach is much too heavyweight. For example, an ACC in the
registry will be represented as a RegistryObject, and will be associated
with its comprising BCCs (which will also be RegistryObjects) using
Registry Associations. We will not create Properties that "sit" between
ACCs and BCCs, because it is not necessary.

(7) We will not implement section 7.5 on, because this information is
meant to redefine/enhance core registry concepts, which is considered
out of scope of the Core Components effort.

(8) We will not represent Content Components, because it is not
necessary to store an additional entity in the registry that represents
the contents of a BCC. This will be taken care of by the assembly
process (which is out of scope of our effort here), in which the data is
placed within the XML tags.

(9) We will not represent Supplementary Components, Supplementary
Component Restrictions, and Content Component Restrictions as individual
entities. This approach is much too heavyweight. Rather, we will
represent the properties of these entities on other entities - for
example, we will represent the Supplementary Component Restriction and
Content Component Restriction properties directly on a Data Type.

(10) We will not represent Content Component Primitive Types at all,
because we will instruct registry implementers to use the pertinent
primitive types according to the CCT that is used. The same will apply
for the CCT properties (codeListID, etc.) - will not have a Slot on a
Data Type for the value of a property, and the primitive type of the
property (too heaveyweight). Registry implementations should enforce the
primitive types according to the properties, as detailed in Table 8-2.
</Deviations>