[Quick Modification] Re: [regrep-cc-review] Re: [regrep] ebXML Registry: Deviations from CCTS

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

Please see [JMC2] for a slight modification.

Chiusano Joseph wrote:
> 
> 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).

[JMC2] The above sentence should state "as a Slot on an ABIE", as Object
Class Qualifiers are represented as Slots on ABIEs, not ACCs.

> 
> 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
> 
> 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-cc-review/members/leave_workgroup.php.