Re: [regrep] ebXML Registry: Deviations from CCTS

[Duane Nickull <dnickull@adobe.com>]

I have some comments (inline):  Can someone please subscribe me to the 
CCTS lists?  I want to join the CEFACT ATG groups working on this 
problem.  Thanks.


Chiusano Joseph wrote:

></Deviations>
>(1) ASCCs and ASBIEs will not be represented as entities as described in
>the CCTS; rather, they will be represented as Registry associations;
>
(DN) This is probably a good idea since this can also be unilateral or 
bilateral in nature.  The mechanism for associations is extensible to 
facilitate this.  Question: has anyone been able to reconcile this 
behavior with UML 2.0 <<stereotypes>> as mechanisms for expressing the 
associations in UML?  We did some work and used the associations 
mechanism quite successfully for this purpose.  

>(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.
>
[DN] This also seems a wise decision.  While there is only one object 
class qualifier allowed in ISO/IEC 11179 Part 2 (2002), do you foresee 
that we should open this up to allowing multiple object class qualifiers 
(multiple inheritance?) to account for logical "ands", "ors", "nors" + 
"nands" when expressing BCC's? An example is that if two or more CC's 
with different qualifier names are the same, can we express that?

>(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.
>
[DN] Also agree in principle since the addition of one qualifier term 
does not necessarily define enough precision to become a BIE.  I believe 
the final solution will be  exponentially more complex.  My 
understanding is that the 8 context qualifiers are to be filled out in a 
series of worksheets (according to UMM) in order to correctly identify 
all 8 context values.  Only then does a *CC become a *BIE.  I am under 
the impression that 8 is only a starter set and more context categories 
will eventually be identified.  The context declaration mechanism must 
support all the logical components (ands. ors, etc) too.  Question:  How 
best to represent this in a registry?  The CCTS recommend using the 
classification schemes to represent Context categories, however, there 
is a huge problem with this based on the sheer magnitude of the 
allowable combinations.  

For example, if you chose to express just 4 context categories and had 
50 values for each possible context, you would have to create 50 to the 
power of 4 classification schemes (or 6,250,000 classification nodes) to 
express all the possible contextual classifications. In reality, the 
numbers are much larger.   With a mere 6.25 million, it would take 
someone years to finish this manually.  Allowing for us to ignore the 
ones that may not be used, the range of possibilities is still far too 
large and IMO will hinder interoperability rather then enhance it.

The questions is how do we represent the entire gamut of classification 
schemes that will be used in the registry, then present them to the 
registry users in a logical (hierarchical?) manner.

The order of contextual classifications is also important.  It is 
probable that Geo-political should be first level classification since 
things like language preferences will impact a persons ability to 
understand anything below in the hierarchical tree.

>(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.
>
[DN] I believe it may lie somewhere between data types and the CC, not 
necessarily on the same level as data type.  Maybe the code lists 
(really the "representations") should be the next logical or physical 
refinement after "data type".  Enumerated lists can be kept as separate 
registry items.  We used a different methodology of using W3C schema to 
represent BIE's since the xs:import function allows dynamic linking of 
code lists for representation terms (as per 11179 methodology).

>(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.
>
[DN] agree.

>(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.
>
[DN] Wise choice  That is also why we used an XML serialization for this 
since the W3C xs:import schema function and the registry's URL strings 
are a good mechanism to allow extraction of *CC's and *BIE's form the 
registry in a machine and human readable form, not bound to any specific 
syntax.

>(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 implementors 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>
>
[DN] I personally believe that the primitive data typing is wrong since 
it has dire consequences in the real world.  The big-endian vs. little 
endian problem of bit ordering will certainly be a gotcha and people 
attempt to implement this on more than one language and rely on the 
registry to serialize results in anything other than XML.  Sticking with 
a common encoding and XML serialization solves this because you can use 
data encodings like ISO-8859-1 or UTF 8 or 16.  The handling of things 
like white space is also addressed in XML.

My.'$0.02'.worth

Duane Nickull

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com