OASIS Universal Business Language (UBL) TC

Re: [ubl] UBL and OAG Common Core Component schemas

  • 1.  Re: [ubl] UBL and OAG Common Core Component schemas

    Posted 04-01-2004 14:21
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl message

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


    Subject: Re: [ubl] UBL and OAG Common Core Component schemas


    Tim,
     
    I just wanted to acknowledge your effort in this regard. I think the degree to which alignment can be accomplished will more than proportionately drive adoption of both specifications.
     
    Kudos,
    Marty
     
    In a message dated 4/1/2004 2:53:34 AM Eastern Standard Time, tmcgrath@portcomm.com.au writes:
    It has been a long standing principle that UBL and OAG would try to
    align their implementations of schemas for Core Component Types and Data
    Types. The intention is that this will provide input into the work of a
    mutually agreed upon standards organization such as UN/CEFACT ATG2 or ISO.

    In August 2003 both groups started with a common initial set of schemas.
    Since that time these have evolved separately to accommodate design and
    implementation issues both within OAGIS 9.0 and UBL 1.0.

    As UBL is about to finalize its 1.0 package it is useful to review these
    differences and attempt to synchronise our developments.

    To this end, Garrett Minakawa (representing OAG) and Tim McGrath
    (representing UBL) have reviewed the current OAGIS 9.0 and proposed UBL
    1.0 schemas.

    We have identified five areas of misalignment:
    1. Naming of Supplementary Components as attributes.
    2. Use of XSD normalizedString for code, identifier and text components.
    3. Use of XSD built-in dataypes requiring format Supplementary Component
    (Date Time, Indicator and Numeric).
    4. Restrictions on Binary Object for Graphic, Picture, Sound and Video
    data type.
    5. Patterns for Indicator data type.

    We would like to propose the following immediate course of action to
    align these schemas.

    Proposed Action Items
    ------------------------

    1. Naming of Supplementary Components as attributes.
    * Analysis:
    UBL have adopted a naming convention for Supplementary Components based
    on the ObjectClass + PropertyTerm + RepresentationTerm rule that applies
    to BIEs.
    OAG have informal naming rules inherited from the initial schemas.
    * Proposal:
    OAG consider adopting the same naming rules as UBL.

    2. Use of XSD normalizedString for code, identifier and text components.
    * Analysis:
    OAG use the built-in XSD type,"token", for all code, identifier and text
    components (where there is no specific built-in type, such as "language").
    UBL uses the built-in XSD type,"normalizedString", for all code and
    identifier components and the built-in XSD type,"string", for all text
    components (where there is no specific built-in type, such as "language").
    * Proposal:
    OAG consider the built-in XSD type,"normalizedString", for all code,
    identifier and text components (where there is no specific built-in
    type, such as "language").
    UBL consider the built-in XSD type,"normalizedString", for all text
    components (where there is no specific built-in type, such as "language").

    3. Use of XSD built-in dataypes requiring format Supplementary
    Component(Date Time, Indicator and Numeric).
    * Analysis:
    OAG explictly define an attribute for "format" in the Core Component
    Type schema. This is then restricted(prohibited) in the data type schema.
    UBL do not define an attribute for "format" in the Core Component Type
    schema. This follows UBL Naming and Design rule [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."
    * Proposal:
    UBL consider relaxing NDR rule STD1 to allow adoption of the OAG approach.

    4. Restrictions on Binary Object for Graphic, Picture, Sound and Video
    data type.
    * Analysis:
    OAG define different attributes for use in data types derived from
    Binary Object (Graphic, Picture, Sound and Video). For example, in OAG a
    Graphic type has characterSetCode,encodingCode,URI and filename whereas
    in UBL, a Graphic type has only mimeCode. (NB this is actually a UBL
    modeling error, it was supposed to have all Supplementary Components
    except the mimeCode).
    * Proposal:
    UBL consider adopting OAG restrictions for Graphic, Picture, Sound and
    Video data type.

    5. Patterns for Indicator data type.
    * Analysis:
    OAG define a pattern of "true" or "false" for their Indicator data type.
    UBL has no pattern.
    * Proposal:
    UBL consider adopting OAG pattern of "true" and "false" for the
    Indicator data type.


    Open Work Items
    ---------------
    We also identified some work areas that both OAG and UBL could jointly
    pursue. These are:

    6. Namespace. OAGIS and UBL use different notation and naming in their
    namespace declarations. This should not be a major issue since it is
    expected that OAGIS and UBL will eventually use the same set of common
    core component schema files once they are officially approved and hosted
    by a mutually agreed upon international standards organization such as
    UN/CEFACT ATG2 or ISO. Once this occurs, OAGIS and UBL will simply
    reference the namespace names adopted by the mutually agreed upon
    standards organization. As long as the content of the common core
    component schema files remain unchanged, there should be no visible
    impact to end users.

    7. Annotation. OAGIS and UBL have different documentation/annotation
    standards but again, this is not expected to be an issue once the common
    core component schema files are implemented by a mutually agreed upon
    international standards organization.

    8.XML Schema Namespace Prefix. OAGIS uses xs: as the namespace prefix
    for http://www.w3.org/2001/XMLSchema. UBL uses the prefix xsd:. As with
    namespaces and annotations, this is not expected to be an issue once the
    common core component schema files are implemented by a mutually agreed
    upon international standards organization.

    9. complexType Naming Convention of Representation Terms. UBL has
    appended the term “Type” to the name of all representation terms in
    “UnspecialisedDataTypes.xsd” (e.g. “AmountType” vs. “Amount”).

    10. Name of RepresentationTerms schema (vs. UnspecialisedDataTypes)

    11. Abbreviation for Identifier (ID vs. Id)

    12. Develop a consistent method for representing prohibited attributes
    (and attributes with no changes from the base type) when using
    derivation by restriction.

    --
    regards
    tim mcgrath
    phone: +618 93352228 
    postal: po box 1289   fremantle    western australia 6160




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


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