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