[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Quick Modification] Re: [regrep-cc-review] Re: [regrep] ebXML Registry: Deviations from CCTS
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.