RELEASE NOTES

The following notes describe the known bugs and design consideration that you should be aware of when using xCBL 3.0, release 2.

What Is New In This Release

Four new documents have been added to those released in December. The new documents are:

• PaymentStatusRequest

• PaymentStatusResponse

• FXRateRequest

• FXRateResponse

In addition to the new documents, two bugs from the December release have been corrected:

• A ProviderID attribute was added to the CatalogProvider element. This change affects the ProductCatalog document.

• A TradingPartnerOrganizationVisibility element was added to the TradingPartnerOrganizationHeader element. This change affects the TradingPartnerOrganizationInformation and TradingPartnerOrganizationDelete documents.

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). The first major design driver 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 in general much sparser than in other document definitions. In many cases, although it might have been slightly easier to process with deeper nesting of containers, etc., these were omitted as being more trouble from a size perspective than they were worth from the standpoint of a developer. Secondly, many aspects of the 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. A large number of catalog content processing systems have solved problems of arbitrary product attribute handling in ways based on XML DTDs, rather than on XML Schema languages. These approaches, although inconsistent with the rest of xCBL, are supported in the ProductCatalog document to allow easier adoption of the format.

Known Bugs

ASNReferences

When a single ASN references several order or account numbers, the placement of the numbers is not obvious.

ASNOrderNumber has a child ListOfMessageID element. In addition to holding the order number used as a reference to the orders being shipped, this element can also contain the account numbers associated with that particular order.

The account numbers should be placed in:

• ListOfMessageID:MessageID:IDNumber (which holds an account number)
• ListOfMessageID:MessageID:IDAssignedBy:IDAssignedByCoded (with the value of "AccountOf")

The entire MessageID construct can be repeated for each account number related to that order reference.

When there is only one account per ASN, it should be mapped to ContractNumber within ASNReferences. The absence of a ListOfMessageID with an "AccountOf" code indicates that this field should be examined.

ASNPartialOrderCode

ASNPartialOrderCode will be changed to something like "PartialOrderCode". This element should not have the "ASN" in front of it, as it is used in documents other than ASN.

ASNBaseItemDetail

Optional DetailResponseCoded and DetailResponseCodedOther fields will be added to ASNBaseItemDetail.

DimensionCoded

DimensionCoded (a single field) will 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.

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.

InvoiceSummary

InvoiceTotals occurrence will be changed to "zero or more".

GPSCoordinates

"GPSCooridinates" will be changed to the correct spelling, "GPSCoordinates".

ListOfBankDetails

BankDetail occurrence will be changed to "one or more". This element is used in the TradingPartnerOrganizationDelete and the TradingPartnerOrganizationInformation documents.

OrderParty

"ManufacturingToParty" in the OrderParty element will be changed to "ManufacturingParty".

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.

Payment Instructions

PaymentTerms occurrence will be changed from "one or more" to "optional" (0..1). It is recommended that, at most, only one occurrence of PaymentTerms be used.

PaymentRequestAcknowledgment Document

Both the component file and the document element will be renamed to reflect the correct spelling: "PaymentRequestAcknowledgement".

Person Communication Type

PersonCommunciationTypeCodedOther occurrence will be changed to "optional" (0..1). This element is used in the TradingPartnerUserInformation and the TradingPartnerUserDelete documents.

PurchaseOrderReference

PartialOrderCoded in the PurchaseOrderReference element will be changed to type PartialOrderCode. This change will be made in conjunction with the ASNPartialOrderCode change specified above.

TradingPartnerOrganizationHeader

The TradingPartnerOrganizationVisibility field, occurrence will be changed to "optional" (0..1).

PackageDescription

ContainerCounter description is incorrect, it should read :- identifies the package sequence with respect to its location to the inner and outer packages. Can also be used to identify locations in a compartmentalized tank car or a pallet, such as 3p or 2nd from brake.

LoadOrderCounter description is incorrect, it should read :- identifies the order in which this package was placed inside it's container.