[Fwd: Re: ebXML Registry: Deviations from CCTS]

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

At the request of at least one SC member, here is the original e-mail
that Fred van Blommestein sent to me, to which I replied yesterday and
copied the CC Review listserv.


Joe

-------- Original Message --------
Subject: Re: ebXML Registry: Deviations from CCTS
Date: Sat, 17 Jan 2004 13:17:25 퍝
From: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
To: <chiusano_joseph@bah.com>
CC: <Alan.Stitzer@marsh.com>

Hi Joe,
 
I got the planned deviations from CCTS by the RegRep team through Alan
Stitzer and took the liberty to comment on it from my personal point of
view. Some of my views hopefully will later be confirmed by material to
be prepared by TGBG17, but I felt it would be good to send you some
reaction as soon as possible.

(1) ASCCs and ASBIEs will not be represented as entities as described in
the CCTS; rather, they will be represented as Registry associations;
 
<Fred>OK with me, as long as you can store the Property Term and its
Qualifier Term(s) with the association.</Fred>

(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.
 
<Fred>If you stay consistent with (1) you would represent BCC's and
BBIE's as associations as well. To make a distinction between "Reusable"
and "Non-reusable" property terms seems awkward and is not supported by
CCTS. You could however draw (some or all) property terms from a
controlled list. You could then add definitions, synonyms and examples
to each property term. As that would be an "extra" feature of the
registry you would not violate CCTS. You should IMHO not make a
distinction between property terms in (1) and in (2).</Fred> 
 
(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.
 
<Fred>
First: the use of qualifiers with ACC's violates the CCTS. Either
qualify it and call it an ABIE or use an adjective instead of a
qualifier to form a multi word term.
Second: The relation between qualifiers and context needs not to be a
one-to-one relationship. One qualifier may be valid in multiple contexts
and within one context multiple qualifiers may be valid. Therefore
applicable contexts should be defined at BIE level rather than on
qualifier level.
</Fred> 
 
(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.
 
<Fred>OK. I foresee that for each CCT an unqualified DT will be defined
anyway.</Fred> 
 
(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.
 
<Fred>To be honest I think that the number of context drivers will be
smaller rather than larger than 8. The complexity will otherwise be too
huge to handle. But I have no problem leaving this open in the
registry.</Fred>
 
(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.
 
<Fred>See (1) and (2). Properties are not Registry Classes according to
CCTS. Properties may IMO be represented as attributes to
associations.</Fred>
 
(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.
 
<Fred>Surely you implement a subset of 7.5. Each registry will contain
administrative info, I assume (like date of entry, registrar, etc.). It
would be good to indicate which elements *are* implemented.</Fred>
 
(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.
 
<Fred>OK</Fred>
 
(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.
 
<Fred>I (with you) think restrictions or facets should be defined on
data type level (see CCTS fig. 7-1).</Fred>
 
(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. 

<Fred>OK</Fred>
 
Fred van Blommestein

------------- 
Dit e-mailbericht en enige bijlage is vertrouwelijk en 
uitsluitend bestemd voor de geadresseerde(n). Indien u niet 
de geadresseerde bent, mag u deze e-mail of enige bijlage niet 
kopieren of aan derden ter inzage geven of verspreiden. 
Indien u deze e-mail per vergissing heeft ontvangen 
verzoeken wij u de afzender ervan onmiddellijk op de hoogte te 
stellen per e-mail en de betreffende e-mail te vernietigen.

This e-mail and any attachment is confidential and may 
contain legally privileged information. If you are not the 
intended recipient, please note that this e-mail or any 
attachment may not be copied or disclosed or distributed to 
others. If you have received this e-mail by error, please notify 
the sender immediately by return e-mail, and delete this message. 
--------------