OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [Fwd: [ubl-ssc] SSC report]


Hi,

I've summarized the discussions and action items from the SSC F2F 
discussion.  Some items require the attention of the TC.  Those are 
noted by a "TC->" in the left margin.  This is somewhat condensed.  The 
complete notes can be found on the SSC mail archive.

-Anne

The SSC F2F discussions focused on reviewing Spreadsheets, Schemas,
EDIFIX, and the NDRs to discover alignment issues, resulting in
proposals for changes to be considered for future development.
We arrived at 5 basic categories/timeframes of needed changes:

  a) 1.0 Release Notes
  b) EDIFIX alignment testing
  c) 1.01 update
  d) 1.1 update
  e) 2.0 issues

Below is a summary report by area and issue, noting actions for each
of the above categories/timeframes, also indicating areas that need
full TC review (indicated by "TC->" in margin).

----------------------
UBL-CoreComponentTypes
----------------------

  1. The  'Component Type' spreadsheet column (column X) needs to
     distinguish 'content' components from 'supplementary' components.
     So possible values for this column will be one of:
     "CCT", "Content", or "Supplementary"

     AIs:
     + EF alignment: Change CCT spreadsheet to use 'Content' value.
     + 1.1: Change CCT spreadsheet to use 'Content' value.

  2. The order of the supplementary components for "Code. Type" and
     "Identifier. Type" should be aligned with the one used in the
     CCT schema and in CCTS 2.01.  [** Also, neither schema nor ss
     are in CCTS order for BinaryObjectType. **]

     AIs:
     + 1.1: Agree to fix in SS.  However, UBL will not formalize the
            sequence of bbies in the ss model, as those are ordered
            for human readability.

  3. Need to resolve handling of "Property Term Possessive Noun"
     and "Property Term Primary Noun" - EF is only able to store
     these entries as user notes.  UBL uses them for modeling.

     AIs:
     + 1.1: Sylvia find out if EF can preserve those columns
            (even if there are values in them, and even if it can't
            preserve the values).  Then if EF can regenerate those
            columns on output (even without the values) we'll just
            regenerate the values manually (by adding the formula).
            Regardless of how EF manages those columns internally,
            the output UBL SS format (columns and column order)
            needs to remain as it is in 1.0.

  4. [MDC1] UBL Libraries and Schemas MUST only use ebXML Core Component
     approved ccts:CoreComponentTypes.

     The UBL CCT schema implements ebXML approved cctypes according
     to CCTS Table 8-1, with three exceptions: numeric, datetime,
     and indicator.  The UBL CCT schemas do not contain the 'format'
     attribute for these three types.  These have been cast as
     'simple' types (which precludes adding more attributes).

     AIs:
TC-> + 1.0 Release Notes: Format attribute in ss but not schema.
     + 1.0.1: Remove format attribute from spreadsheet NumericType.
TC-> + 1.1: Consider the impact of the fact that we have removed the
            'format' attribute and constrained these as simple types.
            Is this really how we want these represented in the future?

  5. The ss and schemas of cctypes are currently quite different
     because EF is not reading the CCT spreadsheet - the CCT schema
     is generated manually as was originally provided by Gunther.

     AIs:
TC-> + 1.1: Decide on need for generation of CC Types.


  6. [STD1] For every ccts:CCT whose supplementary components map
            directly onto the properties of a built-in xsd:Datatype,
            the ccts:CCT MUST be defined as a named xsd:simpleType

     AIs:
TC-> 1.1/ 2.0: CCTypes schema originally done by Gunther and Garret.
               As UBL develops more ccts and rts, will drive the need
               for more dts. Need for analysis of new ccts, looking at
               available built-in dts to see if one meets the
               requirements.  Currently ATG does this.  Need to decide
               whether there is a need for UBL to continue to provide
               a cc types schema.

  7. [CTD7] Every unspecialised Datatype must be based on a ccts:CCT
            represented in the CCT schema module, and must represent
            an approved primary or secondary representation term
            identified in the CCTS.

     In UBL, simple type doesn't restrict underlying the cct, but
     restricts directly the buil-int xsd types.  Not all udts are
     direct restrictions.  This rule doesn't provide for this.

     Basically there is a difference in approach between two atg and
     ubl: in ubl, the udt schema module directly imports the cct shcema
     module and every dt has a direct 1:1 realtionship with its
     corersponding cct.  In ATG, to make (EF) tool development easier,
     every cct in is defined as a complex type and every sc is present
     as an attribute of that cct.  Then, also to levearege buil-in dts,
     there had to be a break in the direct link between cct and udt
     (because you can't turn a complex type into a simple type).
     So that is what is meant by saying the constructs in udt are
     'based on' cct.  Some are simple types where as others are facets
     of built-in xsd dt representations.

TC-> AI: 1.1/2.0: Need resolution on CCTypes in UBL.


--------------------------
UBL-UnspecializedDatatypes
--------------------------

  1. The  'Component Type' column (column X) needs to distinguish
     'content' components from 'supplementary' components.
     So possible values for this column will be one of:
     "DT", "Content", or "Supplementary"

     AIs:
     + EF alignment: Change UDT spreadsheet to use 'Content' value.
     + 1.1: Change UDT spreadsheet to use 'Content' value.
   
  2. Same as #2 above.

  3. Same as #3 above.

  4. "Binary Object", and its secondary representation terms
     ("GraphicType", "PictureType", "SoundType", and "VideoType")
     have "format" and "mimeCode" attributes in the spreadsheets,
     but are missing these attributes in the schemas, which instead
     have one attribute "characterSetCode".

     [** CCTS has additional attributes of filename, encodingcode,
     and uri which are missing in both udt ss and schema. **]

     AIs:
     + EF alignment: only have 'Content' and characterSetCode' in SS.
TC-> + 1.1: Figure out which of these attributes we want to include
            in the long term.

  5. CCTS 2.01 doesn't specify how to generate Dictionary Entry Names
     for Supplementary Components of Secondary Representation Terms.

     UBL has implemented the Supplementary Components for both
     Primary and Secondary Representation Terms as components
     of Unspecialized Datatypes following the same naming rules
     as for CCTs (and CCs and BIEs).  That is the ISO 11179
     ObjectClass+PropertyTerm+RepTerm and seems a logical approach.
     UBL models Secondary Representation Terms (Graphic, Video,
     Date, Time, etc.) as being of the same Object Class as their
     respective Primary Representation Term, but with the Object
     Class qualified by their respective Secondary RT name.
     Example: Graphic type is of object class 'binary object'
     with an object class qualifier of 'graphic'.

     EF handles unspecialized DTs as unqualified DTs and so
     doesn't expect an object class 'qualifier' for these DTs.
     In EF, unqualified DT components should not have an Object
     Class Qualifier, and EF has no way to store qualifiers of
     'unqualified' DTs.  So that information is not being used
     in the schemas.

     Because of this EF has problems creating the Dictionary Entry
     Names for Supplementary Components of unspecialized DTs that
     represent a Secondary Representation term because it doesn't
     use Primary RT rules for these.  So EF disregards the qualifier
     and uses the Secondary RT type name as the name, as it would
     for a Primary RT (Graphic SCs would be prefixed with 'Graphic').

     AIs:
     + EF alignment: David explain how the names for CCs and SCs
                     for secondary RTs are currently generated by EF.
     + 1.1: EF suggest other way to model secondary RTs.
TC-> + 1.1: We need to resolve this difference in naming of SCs of
            Secondary RTs.  If we determine we need DENs for these
            Supplementary Components then we should agree on how
            best to model these and what rules should be applied
            for their naming, as there are currently no rules for
            DEN creation of Content Components and Supplementary
            Components of Secondary RTs in CCTS or UBL.  We need
            a UBL rule (not NDR) which would be an implementation
            of the CCTS naming of Secondary Representation Terms.
            Should here try to align this with the ATG2 expression
            of what they call the UDTs.  Tim will look at this.

  6. Same as CCT section #4 above.

------------------------
UBL-SpecializedDatatypes
------------------------

  1. Same as #1 above.

  2. Same as #2 above.

  3. Same as #3 above.

  4. There is a trailing space in the value for the codeListURI fixed
     attribute of the Country codelist.

     It would be preferrable for EF to add a feature to do general
     trimming of white space (doesn't do this right now) and we must
     fix the SS.

     AIs:
TC-> + 1.0 Release Notes: problem with trailing space in the value for
           the codeListURI fixed attribute of the CountryIdentificaton
           Code codelist in both the SDT spreadsheet and schema.  (This
           effects validity of instances so people should know about it.)
     + EF alignment: Remove trailing space from SDT spreadsheet.
     + 1.01: Remove trailing space from SDT spreadsheet.
     + 1.01: Add white space trimming in EF.

  5. Three attributes used for each of the code types in the spreadsheet
     (codeListNamespacePrefixID, codeListDescription, CodeListCredits)
     are not represented in the schemas.

     AIs:
     + EF alignment: Depending on 1.1 decision, remove UBL-specific
       codelist attributes (prefixid, desc, credits) from SS.
TC-> + 1.1: Decide if we need UBL-specific code list attributes (eg.
       codeListNamespacePrefixID, codeListDescription, CodeListCredits)
TC-> + 1.1: Figure out a better way to represent additional CodeList
       attributes.  EF suggests columns for these.

  6. The SDT spreadsheet incorrectly has the codelist text file
     filename for the "Name" attribute, "Values" column, value.

     EF doesn't currenlty use the sdt spreadsheet at all.
     Work is underway in GEFEG to be able to improve the algorithm
     for importing SDT SS values. Will be done in a couple of weeks.

     AIs:
     + EF alignment: Remove value from 'name' row(s) in SDT SS.
     + EF alignment: Complete SDT import functionality.
TC-> + 1.1: Need to align SDT SS, Codelist model and EF import ability.
             Dependency on completion of Codelist model.

------------------------
UBL-Reusable and MainDoc
------------------------
  
  1. Because CCTS 2.01 doesn't know a "Property Term Possessive Noun"
     and "Property Term Primary Noun" we are only able to store these
     entries as user notes.

     AIs: Same as #3 above.

----------------------
Spreadsheets - General
----------------------

  1. GEFEG would like the UBL SS at minimum to have the same columns
     as the TBG17 SS. 

     AIs:
     + GEFEG provide list of the columns from the TBG17 SS they want
       to see in the UBL SS.

  2. [DOC2] A Datatype definition MAY contain one or more Content
            Component Restrictions to provide additional information
            on the relationship between the Datatype and its
            corresponding Core Component Type.  If used, the Content
            Component Restrictions must contain a structured set of
            annotations in the following patterns:

            • RestrictionType (mandatory): Defines the type of
              format restriction that applies to the Content Component.
            • RestrictionValue (mandatory): The actual value of the
              format restriction that applies to the Content Component.
            • ExpressionType (optional): Defines the type of the regular
              expression of the restriction value.

       See Table 7-1 of CCTS.  Examples of a CC RestrictionType
       for, say, 'String' type would be 'minimum length'.
       The RestrictionValue would be the actual value.
       There must be the above structured set of annotations
       for each restriction.

       Currently UBL has no documentation for Content Components
       or Supplementary Components.

       AIs:
TC->   + 1.1: Review implementation to see if we need to add anything.


  3. Eventually registration of constructs in schemas should
     be automated so can be submitted to registration authority
     and metatdata will automatically go into the registristrion
     process for the schemas.

     AIs:
TC-> + 1.1/2.0: Follow up on registration requirements (CCTS Section 7).

  4. [GNR1] UBL XML element, attribute and type names MUST be in the
            English language, using the primary English spellings
            provided in the Oxford English Dictionary.
     AIs:
TC-> + 1.1: Check SS(s) element, attribute, and type names.


  5. [GNR4] - [GNR6] Acronyms and Abbreviations

     EF checks against NDR, but if acronym is in SS it is left alone.

     AIs:
TC-> + 1.1: Resolve A&A list, usage, ownership, and maintenance.
     + 1.1: Align SS and Schemas with final list and rules.

  6. [GNR7] UBL XML element, attribute and type names MUST be in
            singular form unless the concept itself is plural.

     AIs:
TC-> + 1.1: Check SS for conformance.


  7. [ATN1] Each CCT:SupplementaryComponent xsd:attribute "name" MUST
     be the Dictionary Entry Name object class, property term and
     representation term of the ccts:SupplementaryComponent with the
     separators removed.

     If the object class is identical to the RT of the data type
     (or cct or whatever) then UBL removes the Object Class from the
     name.  EF and SS do the same thing, which is different than what
     it says in this rule.  ELN3 covers elements, but not attributes.

     AIs:
     + 1.1: Review rule for SS UBL name creation.
     + Also see NDR section for rule update

----------------
Schema - General
----------------

  1. [GXS1] UBL Schema MUST conform to the following physical layout ...

       UBL schema organization is different than GSX1:
       - short copyright not the same
       - full copyright should be at end of document
       - need to align order for declaration of namespaces
         and order of imports and follow structure outlined in GSX1
       - include section head comment lines, except when section is
         empty

       GXS1 doesn't include, but UBL comment header currently does include:
       - "Universal Business Language (UBL) Schema 1.0"
       - URLs to UBL and OASIS web sites
       - "Document Type"
       - "Generated On" (date)
       - tribute to Mike
       - additional comment lines for additional clarity

     AIs:
TC-> + 1.1: Review format
     + 1.1: update schemas.

  2. [NMC1] Each dictionary entry name MUST define one and only one
     fuly qualified path (FQP) for an element or attribute.

     EF doesn't explicitly check this, nor duplicate DEN's/names
     for objects.

     AIs:
TC-> + 1.1: Clarify whether there's need for EF to explicity check this.


  3. [VER1] - [VER7] Relating to use of major/minor version numbers.
     ---------------

     There is nothing in EF to automatically create version numbers.
     Now it is done manually; should EF consider automating this?

     AIs:
TC-> + 1.1: Decide on versioning implementation.

  4. [DOC1] The xsd:documentation element for every Datatype MUST
            contain a structured set of annotations in the following
            sequence and pattern:
            • ComponentType (mandatory): The type of component to which
              the object belongs. For Datatypes this must be “DT”.
            • DictionaryEntryName (mandatory): The official name of a
              Datatype.
            • Version (optional): An indication of the evolution over
              time of the Datatype.
            • Definition (mandatory): The semantic meaning of a Datatype.
            • ObjectClassQualifier (optional): The qualifier for the
              object class.
            • ObjectClass(optional): The Object Class represented by
              the Datatype.
            • RepresentationTerm (mandatory): A Representation Term
              is an element of the name which describes the form
              in which the property is represented.
            • DataTypeQualifier (optional): semantically meaningful
              name that differentiates the Datatype from its underlying
              Core Component Type.
            • DataType (optional): Defines the underlying Core Component
              Type.

     UBL supplies only the mandatory set (ComponentType, DEN,
     Definition and RepresentationTerm).  Even though the SS have
     Object Class and Object Class Qualifier, EF can't create these
     optional information items because no rules in ccts.
     Stems from same problem described in UDT section #5.

     AIs:
TC-> + 1.1: Resolve gaps in CCTS for naming requirements for SS/EF.

  5. [DOC2] A Datatype definition MAY contain one or more Content
            Component Restrictions to provide additional information
            on the relationship between the Datatype and its
            corresponding Core Component Type.  If used, the Content
            Component Restrictions must contain a structured set of
            annotations in the following patterns:
            • RestrictionType (mandatory): Defines the type of
              format restriction that applies to the Content Component.
            • RestrictionValue (mandatory): The actual value of the
              format restriction that applies to the Content Component.
            • ExpressionType (optional): Defines the type of the regular
              expression of the restriction value.

            See Table 7-1 of CCTS.  Examples of a CC RestrictionType
            for, say, 'String' type would be 'minimum length'.
            The RestrictionValue would be the actual value.
            There must be the above structured set of annotations
            for each restriction.

     Currently UBL has no documentation for Content Components
     or Supplementary Components.

     AIs:
TC-> + 1.1: Review implementation to see if we should be adding anything.

  6. [ELN4] A UBL global element name based on a qualified
     ccts:BBIEProperty MUST be the same as the name of the
     corresponding xsd:complexType to which it is bound,
     with the qualifier prefixed and with the word "Type" removed.

     It could be that there are elements whose names consist of
     qualifier property term, property term, and representation
     terms that refer to a complex type with the name having
     only the property term and representation term.

     AIs:
     + 1.1: David check correctness of above statement of current situation.
     + 1.1: Check that SS/EF follow rule.

  7. [10.11.04 Anne]
     Regarding
     [DOC4] The xsd:documentation element for every Basic Business
            Information Entity MUST contain a structured set of
            annotations in the following patterns: 
            • ComponentType (mandatory): The type of component to which
              the object belongs. For Basic Business Information Entities
              this must be “BBIE”. 
            • DictionaryEntryName (mandatory): The official name of a
              Basic Business Information Entity.
            • Version (optional): An indication of the evolution over
              time of the Basic Business Information Entity.
            • Definition(mandatory): The semantic meaning of a Basic
              Business Information Entity.

     I don't see that we have any documentation for our BBIEs,
     at least not in the CBC schema.  Is this where it would be?

     AIs:
     + 1.1: Check documentation for BBIEs.

---
NDR
---
  1. [GXS6] The xsd:final attribute MUST be used to control extensions

     AIs:
     + 1.1: Recommend to remove as this is already an xsd tenet.
            No need to restate here and confusing where to apply.
            Or possibly move to CM document.
  2. 

     [SSM10] The ubl:CommonAggregateComponents schema module MUST
              be named “ubl:CommonAggregateComponents Schema Module”

     [SSM12] The ubl:CommonBasicComponents schema module MUST
             be named “ubl:CommonBasicComponents Schema Module”

     [SSM14] The ccts:CoreComponentType schema module MUST
             be named “ccts:CoreComponentType Schema Module”

     [SSM17] The ccts:UnspecialisedDatatype schema module MUST
             be named “ccts:UnspecialisedDatatype Schema Module”

     [SSM19] The ubl:SpecialisedDatatypes schema module MUST
             be named “ubl:SpecialisedDatatypes schema module”

     AIs:
     + 1.1: Need NDR clarification on where these terms are to be used.
     + 1.1: The plurality of the word 'Type' in the module name for
            SSM19 doesn't agree with that of of SSM14 and SSM17.
            UBL implements this word as a plural for all 3 cases
            (agrees with SSM19, but not SSM14 or SSM17).
            Need alignment of rules.
     + 1.1: Should there be rules for the CCP also?


  3. [DOC1] The xsd:documentation element for every Datatype MUST
            contain a structured set of annotations in the following
            sequence and pattern:
            • ComponentType (mandatory): The type of component to which
              the object belongs. For Datatypes this must be “DT”.
            • DictionaryEntryName (mandatory): The official name of a
              Datatype.
            • Version (optional): An indication of the evolution over
              time of the Datatype.
            • Definition (mandatory): The semantic meaning of a Datatype.
            • ObjectClassQualifier (optional): The qualifier for the
              object class.
            • ObjectClass(optional): The Object Class represented by
              the Datatype.
            • RepresentationTerm (mandatory): A Representation Term
              is an element of the name which describes the form
              in which the property is represented.
            • DataTypeQualifier (optional): semantically meaningful
              name that differentiates the Datatype from its underlying
              Core Component Type.
            • DataType (optional): Defines the underlying Core Component
              Type.

     AIs:
     + 1.1: Resolve discrepancy between Rule S28 of CCTS, which says that
            DTs must include Qualifier Term (mandatory), but DOC1 has


  4. [DOC3] A Datatype definition MAY contain one or more Supplementary
            Component Restrictions to provide additional information
            on the relationship between the Datatype and its corresponding
            Core Component Type. If used the Supplementary Component
            Restrictions must contain a structured set of annotations
            in the following patterns:
            • SupplementaryComponentName (mandatory): Identifies the
              Supplementary Component on which the restriction applies.
            • RestrictionValue (mandatory, repetitive): The actual
              value(s) that is (are) valid for the Supplementary Component.

     Don't know where to find this information.  Not in CCP.

     AIs:
     + 1.1: Need clarification/resolution.

  5. [GNR4] - [GNR6] Acronyms and Abbreviations

     Acronym for DUNS not completely specified.

     AIs:
     + 1.1: Update DUNS information in Appendix B.


  6. [ATN1] Each CCT:SupplementaryComponent xsd:attribute "name" MUST
     be the Dictionary Entry Name object class, property term and
     representation term of the ccts:SupplementaryComponent with the
     separators removed.

     If the object class is identical to the RT of the data type
     (or cct or whatever) then UBL removes the Object Class from the
     name.  EF and SS do the same thing, which is different than what
     it says in this rule.

     AIs:
     + 1.1: Change rule.  Something like
       "If the Object Class of the Supplementary Component is identical
        to the Primary Representation Term of the datatype of the
        cctype then the Object Class will be removed."
       This is how cct ss, sdt and udt is probably done.


  7. [CDL5] The name of each UBL Code List Schema Module MUST be
            of the form: 
            {Owning Organization}{Code List Name}{Code List Schema Module}

       UBL uses a completely different naming convention.
       Both the code list declaraion and data types are in the
       code list schema files now.  What should be in a CL file? 

       There was intended to be a section in the schema format
       (as per GXS1) for code lists but this is not there right now
       - somehow gone.  The CDL5 name relates to any time where you
       must refer to the code list, such as in the header or comments
       of the Code List or other schema files or documentation.
       It probably would be best to use this for the 'filename'
       part of the urn as well, but haven't gone there yet.
       Will have to look into this later.

       AIs:
       + 1.1: Revisit with new code list model.



  8. [CTD1] For every class identified in the UBL model, a named
            xsd:complexType MUST be defined.
            Example: <xsd:complexType name="BuildingNameType">

       AIs:
       + 1.1: Clarify 'class'.  Should this be BBIE?

  9. [CTD7] Every unspecialised Datatype must be based on a ccts:CCT
            represented in the CCT schema module, and must represent
            an approved primary or secondary representation term
            identified in the CCTS.

     AIs:
     + 1.1: Need clarification of what is meant by 'must be based on'.
     + 1.1: Need rule covering case where simple type doesn't restrict
            underlying type, but restricts underlying built-in xsd types,
            as in UBL.  Not all udts are direct restrictions.

  10. [9.11.04 Anne]
      This text appears in the NDR after SSM10:

      "By design, ccts:CoreComponentTypes are generic in nature.
      As such, restrictions are not appropriate.  Such restrictions
      will be applied through the application of Datatypes.
      Accordingly, the xsd:facet feature must not be used
      in the ccts:CCT schema module."

      But it seems we do restrict (and extend) our cc types in the
      UBL-CoreComponentTypes-1.0.xsd.

      AIs:
      + 1.1: Check validity of rule w.r.t UBL implementation.


---------
Code List
---------

  Revisit all rules below and any others in NDR when new Code List
  model is available.

  1. [CTD17] Each ccts:SupplementaryComponent xsd:attribute
             user-defined xsd:simpleType MUST only be used when the
             ccts:SupplementaryComponent is based on a standardized
             code list for which a UBL conformant code list schema
             module has been created.

  2. [CDL5] The name of each UBL Code List Schema Module MUST be
            of the form: 
            {Owning Organization}{Code List Name}{Code List Schema Module}

       UBL uses a completely different naming convention.
       Both the code list declaraion and data types are in the
       code list schema files now.  Need rules for What should
       be in a CL file? 

       There was intended to be a section in the schema format
       (as per GXS1) for code lists but this is not there right now
       - somehow gone.  The CDL5 name relates to any time where you
       must refer to the code list, such as in the header or comments
       of the Code List or other schema files or documentation.
       It probably would be best to use this for the 'filename'
       part of the urn as well, but haven't gone there yet.
       Will have to look into this later.

  3. [CDL*] Code List rules.

  4. Regarding [DOC2], can content component restrictions be used to
     limit the allowed values of a code list?  If not, where would
     they be used?

-----
Other
-----

  1. [STD1] For every ccts:CCT whose supplementary components map
            directly onto the properties of a built-in xsd:Datatype,
            the ccts:CCT MUST be defined as a named xsd:simpleType
            in the ccts:CCT schema module.
     AIs:
TC-> + 1.01: Need way to say which cct should use this rule.  Otherwise
             it is up to tools person to figure out which do and which
             don't map, but that is really not a tools issue.
             Should be noted somewhere?




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]