RELEASE NOTES

The following notes describe the known bugs, design considerations and other things that you should be aware of when using xCBL 3.5.

What Is New In This Release

xCBL 3.5 is made up of 9 new documents and changes to existing documents from xCBL 3.0. The changes to xCBL 3.0 only include the addition of new optional elements, new code values, and the change of occurence from either optional to optional to many, or mandatory to mandatory to many. The exception to this include some of the changes to the ProductCatalog document. The details are as follows:

New Documents:

In addition to these 9 new general-purpose documents, this release also contains several new documents that are more application-specific, tailored to particular ERP system interfaces. These were built using the xCBL component library by a member of the xCBL user community but because of their narrower purpose they are not considered part of the public library. These documents are included in the xCBL 3.5 namespace for efficiency in managing the xcbl 3.5 release. These documents may, at some point, become part of xCBL but until then are subject to change at any time. Please visit Application Specific Documents to learn more.

Changes To Existing Documents:

File Updated Description

xCBL 3.5 Change List October, 2001 This document outlines the changes made and bugs fixed from xCBL 3.0 to xCBL 3.5 Requires Microsoft Excel. To download, right click on the link and choose "Save Target/Link As..."

Field Lengths

There was much debate during the design of xCBL about the restriction of field lengths to support interoperability. The following ideas have been suggested:

• Adopt a common standard - UN/EDIFACT, X12, or similar - as a guide in limiting the lengths of fields

• Use a series of breakpoints that coincide with the retrieval and storage capabilities of common relational systems. This would result in very generous, but still limited, field lengths.

• Have no limits. Just as XML does not limit lengths the way positional syntax does, schemas should not limit field lengths (except in the most obvious cases, such as numeric types like prices).

We decided not to limit field lengths. This decision is based on the idea that trading communities would identify their own needs in terms of interoperability, legacy system requirements, application support, etc. Creators and maintainers of applications and portals must decide on a policy in this area and then document it for the members of their community. Both UN/EDIFACT and X12 provide useful guidelines, based on legacy requirements (typically, X12 has longer maximum lengths than UN/EDIFACT).

Additionally, some emerging standards (ebXML and IFX, to name but two) will probably be making their own recommendations in these areas. These recommendations will be of great importance in the design of future versions of xCBL but were not final at the time of this release.

The ProductCatalog Document

A number of factors resulted in a ProductCatalog structure that is in some ways inconsistent with the bulk of xCBL, although this is not true in all cases (many standard xCBL constructs are used in ProductCatalog). xCBL 3.5 ProductCatalog has been kept backwards compatible, but has introduced new fields enabling use of ProductCatalog in a fashion similar to the rest of xCBL.

The first major design driver in xCBL 3.0 was file size: unlike most transactional documents, ProductCatalog instances will, in many cases, not be merely large, but huge. The markup becomes a significant burden when handling documents of larger size, slowing processing times. Because of this, the markup in ProductCatalog is sparser than in other document definitions. In many cases, deeper nesting of containers, etc., were omitted as having a negative impact on size, and no appreciable improvement in expressiveness.

Secondly, many aspects of the original xCBL 3.0 ProductCatalog document are more "typical" XML DTD constructs than straight xCBL constructs. These include such things as the use of ID/IDREF, and the use of xml:lang. All use of ID/IDREF(S) are deprecated in xCBL 3.5 ProductCatalog, with similarly named elements taking the place of the corresponding XML attributes.

Known Bugs

ASNPartialOrderCode

ASNPartialOrderCode should be changed to "PartialOrderCode", as it is used in documents other than ASN. This bug existed in xCBL 3.0, and was not changed in xCBL 3.5 due to the design constraints.

DimensionCoded

DimensionCoded (a single field) should be updated to include two new sets of codes, each with an "Other" field in support, and an enumerated set of coded values: MeasurementPurposeCoded and MeasuredPropertyCoded. Again, this issue could not be addressed in xCBL 3.5 because of the design constraints.

This change along with a number of minor changes in the next release should improve legacy EDI support. Reviews are ongoing, and should result in an increasingly powerful support for existing EDI standards.

GPSCoordinates

"GPSCooridinates" should be changed to the correct spelling, "GPSCoordinates". Due to the design constraints, this could not be corrected.

ListOfBankDetail

BankDetail occurrence will be changed to "one or more". This element is used in the TradingPartnerOrganizationDelete and the TradingPartnerOrganizationInformation documents. After review of this, it was decided that this change was not necessary, since the occurence of the ListOfBankDetail was already "one to many".

OrderParty

"ManufacturingToParty" in the OrderParty element should be changed to "ManufacturingParty". The design constraints did not allow the change to be made.

Package Quantity

Currently there is an element to define the quantity of an item that is contained within a package at the level of the package element. However, it is possible to define the quantity contained within a package at the item level. This can be achieved by using the Quantity element of the PackageReference element at the item level. Since items are referenced at the package level using the OrderReferences element, which is used elsewhere, inserting a quantity into this, would confuse the matter in the context of other documents.

Payment Instructions

PaymentTerms occurrence should be changed from "one or more" to "optional" (0..1). This change could not be made under the design constraints. It is recommended that, at most, only one occurrence of PaymentTerms be used.

PaymentRequestAcknowledgment Document

Both the component file and the document element should be renamed to reflect the correct spelling: "PaymentRequestAcknowledgement", however, this was not possible under the design constraints.

Person Communication Type

PersonCommunciationTypeCodedOther occurrence should be changed to "optional" (0..1). This element is used in the TradingPartnerUserInformation and the TradingPartnerUserDelete documents. The constraints of xCBL 3.5 did not allow this change.

ProductCatalog-Language

In the xCBL 3.5 ProductCatalog the CatalogHeader/DefaultLanguage is intended to set the default language for an instance of the document. The default for CatalogHeader/DefaultLanguage, if no value is specified, is "en" (English). Elsewhere in the ProductCatalog language for various elements can be set using the xml:lang attribute. The xml:lang attribute also has a default of "en" if no value is specified. Having a default specified for the xml:lang attribute is a bug and may cause the default language to be something other that was specified by CatalogHeader/DefaultLanguage. For example, if and instance of the ProductCatalog has CatalogHeader/DefaultLanguage=fr for French and none of the other xml:lang attributes are set then the default becomes “en” (English). The work around for this problem is to set every xml:lang attribute to the preferred language if the preferred language is other than "en"(English).

PurchaseOrderReference

PartialOrderCoded in the PurchaseOrderReference element should be changed to type PartialOrderCode. As with the ASNPartialOrderCode change specified above, this could not be done.

TradingPartnerOrganizationHeader

The TradingPartnerOrganizationVisibility field occurrence should be changed to "optional" (0..1), but the design principles of xCBL 3.5 would not allow this change.