Re: [ubl] IMPT: Ongoing work items

[jon.bosak@sun.com]

[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.

Done.

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

See more on this from Mike Grimley below.

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

Done.

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

Does anyone see this as a live issue?  Speak up now if you do or
I'll cut it.

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

I need to break this out as a separate item for discussion.

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

I don't disagree with this, but I don't think it's necessary to
extend the passage beyond what it already says.  We are committed
to cooperating with a lot of groups; we don't need to say that
here.  People who want more information about TBG17's charter can
follow the link.

[GrimleyMJ@Npt.NUWC.Navy.Mil:]

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

Done.

Jon