RE: [ubl] IMPT: Ongoing work items

[<MCRAWFORD@lmi.org>]

Thanks to Michael for the clarification.  I agree with him (although why we wouldn't keep all of the BCC Property declarations together for consistency and maximum reuse is beyond me)

Mark 


> -----Original Message-----
> From: Grimley Michael J NPRI [mailto:GrimleyMJ@Npt.NUWC.Navy.Mil]
> Sent: Thursday, April 15, 2004 2:13 PM
> To: ubl@lists.oasis-open.org
> Subject: RE: [ubl] IMPT: Ongoing work items
> 
> 
> 
> Agree with all of Mark's proposed changes with one modification:
> 
> From Mark:
> > In UBL 1.0, all BBIE properties are declared as elements and
> > defined as complex types in the Common Basic Components schema
> > (Section 6.2.1).Alternatively, these constructs could be defined
> > in either the Common Aggregate Components schema or in the
> > individual document schemas where they are used.  This issue
> > remains open, but any change in future releases should not affect
> > UBL 1.0 instances.
> 
> No one has proposed defining the types in any schema but the 
> CBC, so it is only some  *declarations* that may be moved.
> The only elements that have been considered for declaration 
> in other schemas are the Qualified BBIE Properties (e.g. 
> 'AdditionalStreetName') because they are a legitimate reuse 
> of an Unqualified BBIE Property (an 'AdditionalStreetName' is 
> of type 'StreetNameType').
> 
> So maybe a combination of a modified Jon's and Mark's:
> 
>     In UBL 1.0, all BBIE properties are declared as elements 
> and defined as complex types in the Common Basic Components 
> schema (Section 6.2.1). Alternatively, the qualified BBIE 
> property elements could be declared in either the Common 
> Aggregate Components schema or in the individual document 
> schemas where they are used.  This issue remains open, but 
> any change in future releases will not affect UBL 1.0 instances.
> 
> 
> 
> -----Original Message-----
> From: MCRAWFORD@lmi.org [mailto:MCRAWFORD@lmi.org] 
> Sent: Thursday, 15 April 2004 13 22
> To: jon.bosak@sun.com; ubl@lists.oasis-open.org
> Subject: RE: [ubl] IMPT: Ongoing work items
> 
> >    UBL 1.0 achieves the basic objective of the first phase of the
> >    UBL charter — to develop a workable standard library of
> >    XML business documents.  The second phase (UBL 2.0) is intended
> >    to produce a mechanism for the automatic generation of
> >    context-specific business schemas.  
> 
> Recommend rewriting second sentence as follows:
> 
> The second phase (UBL 2.0) is intended to produce additions 
> to the UBL library and schema set and a mechanism for the 
> automatic generation of context-specific business schemas.  
> 
> > H.1.4 Location of Qualified BBIE Property Element Definitions
> > 
> >    In UBL 1.0, all qualified BBIE property elements are defined in
> >    the Common Basic Components schema (Section 6.2.1).
> >    Alternatively, these elements could be defined in either the
> >    Common Aggregate Components schema or in the individual
> >    document schemas where they are used.  This issue remains open,
> >    but any change in future releases should not affect UBL 1.0
> >    instances.
> 
> Not sure who raised this nor do I agree with it as it further 
> breaks the entire UBL modularity model that was developed by 
> NDR after many months of discussion and analysis.  However, 
> recommend rewriting as follows:
> 
>  In UBL 1.0, all BBIE properties are declared as elements and 
> defined as complex types in the Common Basic Components 
> schema (Section 6.2.1).Alternatively, these constructs could 
> be defined in either the Common Aggregate Components schema 
> or in the individual document schemas where they are used.  
> This issue remains open, but any change in future releases 
> should not affect UBL 1.0 instances.
> 
> >H.2.2 Version Element in the Documentation of Every BIE
> 
>   > UBL 1.0 assumes that the version number of each UBL BIE is also
>   > 1.0.  However, as reusable BIEs become available from
>   > registries and customised libraries, it is possible that BIEs
>   >may be used outside of their original release.  This may result
>   > in a requirement to assign a version number to each BIE in
>   >future versions of UBL.
> 
> Absolutely disagree with the inclusion of this in the 
> release.  There are no BIEs in the schema.  The versioning is 
> linked to the schema constructs, not the individual BIEs.  
> When an underlying BIE is changed, it WILL result in a new 
> version of the schema - either major or minor depending on 
> its level of change.
> 
> > H.2.1 Relative Paths in Schema Modules
> > 
> >    UBL 1.0 has been released using relative path names for the
> >    location of schemas in order to facilitate offline validation
> >    and to work around current naming limitations on the OASIS web
> >    site.  Use of absolute paths and a registry for the component
> >    library will be considered as the supporting infrastructure
> >    becomes available.
> Recommend changing to:
> 
> UBL NDR identified a requirement for absolute path names for 
> schema locations as a necessary requirement for standards 
> based schemas to ensure consistency, clarity, and absolute 
> assurances that the UBL normative schema are in fact being 
> used.  However, current OASIS architecture limitations 
> preclude the availability of a suitable registry/repository 
> to support this requirement.  As a result, UBL 1.0 has been 
> released using relative path names for the  location of 
> schemas in order to facilitate offline validation and to work 
> around those limitations.  Use of absolute paths and a 
> registry for the component library will be implemented in a 
> future version as the supporting infrastructure  becomes available.
> 
> > H.3.3 Common CCTS Schemas
> > 
> >    The schemas for Core Component Types and Datatypes included in
> >    this package (Section 6.2.2) were developed in cooperation with
> >    representatives of the Open Applications Group, Inc., but the
> >    versions currently used by the two organizations are not yet
> >    identical.  Differences between the CCTS schemas used in UBL
> >    1.0 and OAGIS 9.0 have been identified in these five areas:
> > 
> >     - Naming of Supplementary Components as attributes
> > 
> >     - Use of XSD normalizedString for code, identifier, and text
> >       components
> > 
> >     - Use of XSD built-in dataypes requiring format Supplementary
> >       Components (Date Time, Indicator and Numeric)
> > 
> >     - Restrictions on Binary Object for Graphic, Picture, Sound
> >       and Video data type
> > 
> >     - Patterns for Indicator data type
> 
> >The UBL TC is forming a team to work with OAG members in the 
> >construction of a single set of schemas that can be used by both 
> >organizations and intends to adopt the common schemas in the UBL 1.1 
> >time frame.
> 
> Recommend recognizing that in fact UN/CEFACT ATG has been 
> part of the effort discussed above from the beginning and in 
> fact the UN/CEFACT and OAG versions of the schema are much 
> more closely aligned that UBL and OAG.  Further, recommend 
> rewriting the last sentence as follows:
> 
> The UBL TC has long recognized that UN/CEFACT, as the owner 
> of the CCTS specification, should publish the normative CCT 
> and unspecialised Datatype schema modules.  UN/CEFACT is 
> committed to working with UBL, OAG, and others to make this 
> requirement a reality.  It is anticipated that the UN/CEFACT 
> CCT and unspecialised datatype schema modules will be 
> published prior to the next release of UBL, and UBL commits 
> to adopting those schema modules when available. 
> 
> H.3.4 Core Component Harmonisation
> > 
> >    As an implementation of [CCTS], UBL supports the concept of a
> >    common semantic library of business components. To achieve
> >    this, UBL is working with the UN/CEFACT International Trade and
> >    Business Procedures Working Group on Harmonisation, known as
> >    TBG17
> >    (http://webster.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm).
> >    This group is responsible for consistency and harmonisation of
> >    business process models and core components across business
> >    domains and sectors, contributing to a concise and well-defined
> >    glossary of business terms, business data semantic definitions,
> >    and structuring of data exchanges.  Cooperation with TBG17 is a
> >    continuing work item for UBL.
> 
> recommend rewriting to reflect that UBL is working with TBG, 
> not just TBG17 - and that TBG17 is responsible for 
> harmonization across not only TBG groups, but all external 
> standards organizations such as UBL who wish to work towards 
> a common library. 
> 
> Mark 
> 
> 
> 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.