[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda for Atlantic UBL TC call 30 November 2004
AGENDA FOR ATLANTIC UBL TC MEETING 16H00 - 18H00 UTC WEDNESDAY 30 NOVEMBER 2004 08h00 - 10h00 Wed San Francisco 11h00 - 13h00 Wed Washington 16h00 - 18h00 Wed London ############################################# STANDING INFORMATION FOR UBL CONFERENCE CALLS U.S. domestic toll-free number: (866)839-8145 Int. access/caller paid number: (865)524-6352 Access code: 5705229 ############################################# As previously announced, Mavis will be chairing this call. STANDING ITEMS Additions to the calendar (http://ibiblio.org/bosak/ubl/calendar.htm) Liaison reports (if any) Subcommittee reports (if any) Team reports (if any) ISSUES FOR DISCUSSION THIS MEETING The chief technical work for this meeting is completing processing of the list of issues reported by the SSC. We have to resolve these issues before we can begin the new meeting structure we decided on in Santa Clara. The minutes of the preceding two TC calls show that we have disposed of a number of these issues, but many still remain; at my request, Anne has prepared a list of the ones that appear still to be pending: see below. With regard to Code Lists, we need a timeline showing the Code List Team's plan to hit the 15 April 2004 deadline for last changes to the spec. Jon Bosak Chair, OASIS UBL TC ================================================================== [Numbers are taken from original SSC f2f report for cross reference.] UBL-CoreComponentTypes: 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). Actions/Questions for TC: - Are there going to be Release Notes published somewhere, sometime? - Consider the impact of the fact that we have removed the 'format' '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. 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 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. Actions/Questions for TC (for 5,6, and 7): - Decide on need for generation of CC Types and UDT by UBL. Work towards convergence with ATG2. Obvious concerns: impact on legacy and the fact that ATG2 has always been a moving target, hence the misalignment we find ourselves in now, as our current implementation was put forward as the ATG2 method. Determine actions and timeline. UBL-UnspecializedDatatypes: 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". - Same issue as above (CCT/UDT alignment/structure). UBL-SpecializedDatatypes: 5. Three attributes used for each of the code types in the spreadsheet (codeListNamespacePrefixID, codeListDescription, CodeListCredits) are not represented in the schemas. Actions/Questions for TC: - Agreement from Jon that CodeListCredits are not needed any longer. 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. Actions/Questions for TC: - Need to align SDT SS, Codelist model and EF import ability. Dependency on completion of Codelist model. Spreadsheets - General: 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. Actions/Questions for TC: - Review implementation to see if we need to add anything. Mark, 20041106: The overall requirement for schema documentation is to provide for all documentation required by CCTS. This will position the ubl library as expressed in the spreadsheets to be stored as ebXML conformant core components. 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. Actions/Questions for TC: - 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. Actions/Questions for TC: - 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. Actions/Questions for TC: - Resolve A&A list, usage, ownership, and maintenance. - Align SS and Schemas with final list and rules. Mark, 20041106: The candidates need to be discussed by the entire TC once the list is made. Remember, it must be globally unique to be considered. We have already violated this tenant with non-globally unique acronyms and must exercise greater diligence in the future. 6. [GNR7] UBL XML element, attribute and type names MUST be in singular form unless the concept itself is plural. Actions/Questions for TC: - 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. Actions/Questions for TC: - Review rule for SS UBL name creation. - See NDR section below for ATN1 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 Actions/Questions for TC: - Review schema layout/format - Update schemas to agreed layout. - Change rule accordingly for 1.1 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. Mark, 20041106: Remember – FQP as the DEN not CCTS defined DEN Actions/Questions for TC: - 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? Mark, 20041106: This is more than an EF issue. We are also somewhat limited by EF’s non-registry/non-database approach. We need to decide how we are going to handle versioning of individual components in the spreadsheet. Actions/Questions for TC: - Decide on versioning implementation. - Decide on strategy for storage/registry. 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. Mark, 20041106: Not sure I understand the EF constraint here. Actions/Questions for TC: - 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. Actoins/Questions for TC: - Review implementation to see if we should be adding anything. ----------------------------------------------------------------------- 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. Mark, 20041106: This rule was originally left in because it was internal guidance for development of the extension methodology. There is no requirement to use xsd:final in xsd – it is just available for use. The extension methodology folks could just have easily said that “the annotation documentation element will contain detailed guidance on which element should be considered the “final” element for controlling extensions..” I recommend the rule remains as is. 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. Mark, 20041106: Concur. + 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. Mark, 20041106: I would have preferred that UBL implemented in conformance to SSM14 and SSM17. + 1.1: Should there be rules for the CCP also? Mark, 20041106: Yes. 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 it as 'optional'. Mark, 20041106: We have already covered this. Rule S28 in CCTS is on the “to be fixed” list. 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. Mark, 20041106: This would be information that is already available for those few Supplementary Components who have a predefined restriction in CCTS, or that the library developers would create as part of defining a new SDT. May require new spreadsheet column to make more readily available for schema generation. 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. Mark, 20041106: Not sure I agree with changing the rule. Would like more discussion/thought on this. 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. Mark, 20041106: The code list schema modules still need to follow this naming convention. 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? Mark, 20041106: In UBL 1.0 NDR we treat BBIE Properties as well as ABIEs as classes. See the sentence preceeding the rule which explicitly states this. We may need to separately handle type definitions for BBIE Properties in UBL 1.1 NDR. 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'. Mark, 20041106: Noted. + 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. Mark, 20041106: See previous comments regarding adopting CEFACT ATG CCT and UDT schemas which address this concern. 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. Mark, 20041106: Please identify exactly what restrictions/extensions are applied in the CCT schema module. If not specified in CCTS, then that is a fatal conformance issue. We also probably need to insert the word specialized in front of the word datatypes. ------------------------------------------------------------------- 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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]