[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] IMPT: Ongoing work items
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]