OASIS Universal Business Language (UBL) TC

Re: UBL and OAG Common Core Component schemas

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

    Posted 04-01-2004 20:54
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl message

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


    Subject: Re: UBL and OAG Common Core Component schemas


    I congratulate Tim and Garret for taking the initiative to develop
    this convergence plan for Common Core Component schemas.  This is
    quite an accomplishment, and I think I speak for the whole UBL TC
    in expressing our appreciation for the work.  We now have a clear
    roadmap for moving forward together with OAG on this matter, and
    if no one expresses an objection, I will assume that we are agreed
    on the general direction that Tim and Garret have outlined for us.
    
    Regarding timing, however, I'm not clear on the impact that this
    plan will have on our release schedule.  I'm assuming that we will
    do what we can without materially changing our schedule and defer
    the rest for UBL 1.1, but I'm not sure which item falls into which
    category.  The breakdown of the items proposed for immediate
    action appears to be as follows:
    
    1. Naming of Supplementary Components as attributes
    
       No action for UBL.
    
    2. Use of XSD normalizedString for code, identifier and text
       components
    
       Our action would be: 
    
          UBL consider the built-in XSD type,"normalizedString", for
          all text components (where there is no specific built-in
          type, such as "language").
    
       Is this something we can fit into this cycle?
    
    3. Use of XSD built-in dataypes requiring format Supplementary
       Component (Date Time, Indicator and Numeric)
    
       Our action would be:
    
          UBL consider relaxing NDR rule STD1 to allow adoption of the
          OAG approach.
    
       Two questions here:
    
        - Are we OK with changing our rule to accommodate convergence
          with OAG on this item?
    
        - Is this something that we can accomplish within our current
          schedule?
    
    4. Restrictions on Binary Object for Graphic, Picture, Sound and
       Video data type
    
       Our action would be:
    
          UBL consider adopting OAG restrictions for Graphic, Picture,
          Sound and Video data type.
    
       Is this something we can accomplish within our current
       schedule?
    
    5. Patterns for Indicator data type
    
       Our action would be:
    
          UBL consider adopting OAG pattern of "true" and "false" for
          the Indicator data type.
    
       Is this something we can accomplish within our current
       schedule?
    
    ACTION: I need everyone actively involved in this build cycle
    to consider these questions and be ready to determine a course of
    action in tomorrow's joint SC call (7 a.m. California time at the
    usual UBL number).  Since these decisions will involve LC, NDR,
    TT, and possible CL issues, I urge everyone with an opinion on
    this to participate.  What we decide tomorrow morning will
    determine which parts of this plan can be implemented in 1.0 and
    which will have to be picked up in 1.1.
    
    Please feel free to respond to these questions in mail to the main
    ubl list before tomorrow's meeting.  It would be very useful to
    have some timing estimates from the people who are going to be
    implementing the changes.
    
    Jon
    
    ==================================================================
    
       Date: Thu, 01 Apr 2004 15:54:55 +0800
       From: Tim McGrath <tmcgrath@portcomm.com.au>
       CC: Garret.Minakawa@oracle.com
    
       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]