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:
There was much debate during the design of xCBL about the restriction of field lengths to support interoperability. The following ideas have been suggested:
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.
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 (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.
"GPSCooridinates" should be changed to the correct spelling, "GPSCoordinates". Due to the design constraints, this could not be corrected.
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".
"ManufacturingToParty" in the OrderParty element should be changed to "ManufacturingParty". The design constraints did not allow the change to be made.
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.
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.
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.
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).
PartialOrderCoded in the PurchaseOrderReference element should be changed to type PartialOrderCode. As with the ASNPartialOrderCode change specified above, this could not be done.
The TradingPartnerOrganizationVisibility field occurrence should be changed to "optional" (0..1), but the design principles of xCBL 3.5 would not allow this change.