ontolog-forum
[Top] [All Lists]

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

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Cc: jon.bosak@xxxxxxx
Cc: Garret Minakawa <garret.minakawa@xxxxxxxxxx>
From: Peter Yim <peter.yim@xxxxxxxx>
Date: Sun, 11 Apr 2004 09:48:02 -0700
Message-id: <407976C2.5090401@xxxxxxxx>
fyi ... (esp. those on the [CCT-Rep] team.  -ppy
--    (01)

jon.bosak@xxxxxxx wrote Thu, 1 Apr 2004 13:09:41 -0800 (PST):    (02)

> 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.    (03)

> 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:    (04)

> 1. Naming of Supplementary Components as attributes
> 
>    No action for UBL.    (05)

> 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?    (06)

> 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.    (07)

>    Two questions here:    (08)

>     - Are we OK with changing our rule to accommodate convergence
>       with OAG on this item?    (09)

>     - Is this something that we can accomplish within our current
>       schedule?    (010)

> 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?    (011)

> 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?    (012)

> 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.    (013)

> 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    (014)

> ==================================================================
> 
>    Date: Thu, 01 Apr 2004 15:54:55 +0800
>    From: Tim McGrath <tmcgrath@xxxxxxxxxxxxxxx>
>    CC: Garret.Minakawa@xxxxxxxxxx
> 
>    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.
> 
> 
> 
> 
> 
> 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.
> 
>     (015)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config: 
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (016)
<Prev in Thread] Current Thread [Next in Thread>
  • [ontolog-forum] Re: [ubl] Re: UBL and OAG Common Core Component schemas, Peter Yim <=