|Chiusano Joseph||Jan 7, 2004 8:57 am|
|Duane Nickull||Jan 7, 2004 10:52 am|
|David RR Webber||Jan 7, 2004 11:49 am|
|Duane Nickull||Jan 7, 2004 12:19 pm|
|Duane Nickull||Jan 7, 2004 12:31 pm|
|David RR Webber||Jan 7, 2004 12:35 pm|
|Chiusano Joseph||Jan 7, 2004 2:07 pm|
|Chiusano Joseph||Jan 7, 2004 2:11 pm|
|Chiusano Joseph||Jan 8, 2004 5:49 am|
|Subject:||ebXML Registry: Deviations from CCTS|
|From:||Chiusano Joseph (chiu...@bah.com)|
|Date:||Jan 7, 2004 8:57:25 am|
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.
</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>