Re: [regrep] ebXML Registry: Deviations from CCTS

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

Thanks for your great comments Duane - please see my comments marked
with [JMC]. 

Duane Nickull wrote:
> 
> 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?

[JMC] Our registry representation for Core Components will absolutely
allow multiple Object Class Qualifiers - for example, one may need to
represent an ABIE called US_PurchaseOrder_Document. Details, which would
have 2 Object Class Qualifiers (US and PurchaseOrder). Each Object Class
Qualifiers will be represented as a Slot on an ACC (as will the Object
Class).

Regarding the logical operations, these will be possible by query
operations on the RegistryObjects and Slots. I know that Filter Query
does not allow these types of operations, but SQL Query does - however,
our SQL Query support does not specify how to include Slots in queries.
Sounds like we should consider including some of this functionality in
our v4 spec?

Equivalence testing should also be possible by operations on the Slots
(i.e. comparing Slots that represent Object Classes and Object Class
Qualifiers between 2 different RegistryObjects).

> >(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.  

[JMC] I believe that we should allow users to define the categories
beyond the 8 "built-in" categories that they consider to be
"BIE-producing" categories - that is, those classification schemes that,
when a BCC is associated with one of their nodes, will result in that
BCC becoming a BBIE.

I am under the impression that 8 is only a starter set and more context
categories > will eventually be identified.  

[JMC] Great - we can point implementers/users to the UN/CEFACT work in
this area for their future reference.

The context declaration mechanism must support all the logical
components (ands. ors, etc) too.  

[JMC] Absolutely - we are leaving this to the context/assembly
mechanisms, which are out of the scope of our work. We provide the
ability to establish context through the registry classifications and
the qualifiers, etc. - but automating that process to a further degree
than is specified in our current registry architecture is for a
different effort.

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.

[JMC] I consider this concept to be inherent to the registry and
therefore out of scope of the Core Components effort. We are planning to
use the registry classification schemes to represent context, and if
there are issues with scaling of these schemes we leave it to the
Registry TC to address them.

> 
> 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. 

[JMC] Yes - but that assumes that every Core Component will need to be
associated with every classification node of every classification scheme
in the registry, doesn't it? And if so, how likely is that?


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.

[JMC] Ah yes - we are leaving this to the assebly process as well. I
think this relates more to the order of the Object Class Qualifiers
(considering an ACC to ABIE transition) rather than the order in which
the classifications are done. Our assumption is that the user will
select an ACC (for example) and associate it with whatever
classification schemes they would like, in whatever order they believe
is correct - and the Object Class Qualifiers will be added in the order
that the classification nodes were selected. 

I envision that an assembly tool would require a configurer to specify
this order somewhere as a global setting, and it would be followed upon
classifications - that is, if the user in the example above selected
Language Preferences first and then Geopolitical, but the configuration
says that the order of Object Class Qualifiers (from left to right)
should be Geopolitical (e.g. "US") then Language Preferences (e.g.
EN-US), then that is the ultimate order in which the Object Class
Qualifiers will be added to the ABIE in the registry. We are assuming
for the time being that a Slot will be an ordered collection, so the
order of Qualifiers will be properly set so that it can be properly
reflected upon XML serialization when the element names are constructed.

> >(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.  

[JMC] Interesting idea - what would we call this new entity that lies
between Data Types and CCs? But if a Data Type were called "Country.
Code. Type", wouldn't the proper place for the metadata of the code list
be the Data Type itself?

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.  

[JMC] Could you please provide more specifics? I understand what you are
saying regarding big/little-endian bit ordering, but how does that
relate to the CCTS primitive types? Wouldn't that (and encoding) be an
implementation issue?

[End of JMC comments]

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