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: Re: [regrep] ebXML Registry: Deviations from CCTS


Now that awareness of these issues has been risen to a wide audience
(that was my aim), we will continue the discussions within the CC Review
listserv. If anyone Registry TC is not a member of the CC Review
listserv and would like to participate in continuing these discussions,
we would be very happy to have you join the CC Review SC.


Chiusano Joseph wrote:
> 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>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.

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