|Chiusano Joseph||Jan 7, 2004 8:57 am|
|Duane Nickull||Jan 7, 2004 10:52 am|
|David RR Webber||Jan 7, 2004 11:49 am|
|Duane Nickull||Jan 7, 2004 12:19 pm|
|Duane Nickull||Jan 7, 2004 12:31 pm|
|David RR Webber||Jan 7, 2004 12:35 pm|
|Chiusano Joseph||Jan 7, 2004 2:07 pm|
|Chiusano Joseph||Jan 7, 2004 2:11 pm|
|Chiusano Joseph||Jan 8, 2004 5:49 am|
|Subject:||Re: [regrep] ebXML Registry: Deviations from CCTS|
|From:||Duane Nickull (dnic...@adobe.com)|
|Date:||Jan 7, 2004 10:52:02 am|
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.
(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.
-- Senior Standards Strategist Adobe Systems, Inc. http://www.adobe.com