RE: [ubl] IMPT: Ongoing work items

[<MCRAWFORD@lmi.org>]

>    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