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:
In addition to the new documents, two bugs from the December release have been corrected:
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). 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.
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:
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 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.
Optional DetailResponseCoded and DetailResponseCodedOther fields will be added to ASNBaseItemDetail.
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.
InvoiceTotals occurrence will be changed to "zero or more".
"GPSCooridinates" will be changed to the correct spelling, "GPSCoordinates".
BankDetail occurrence will be changed to "one or more". This element is used in the TradingPartnerOrganizationDelete and the TradingPartnerOrganizationInformation documents.
"ManufacturingToParty" in the OrderParty element will be changed to "ManufacturingParty".
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.
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.
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.
PartialOrderCoded in the PurchaseOrderReference element will be changed to type PartialOrderCode. This change will be made in conjunction with the ASNPartialOrderCode change specified above.
The TradingPartnerOrganizationVisibility field, occurrence will be changed to "optional" (0..1).
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.
HOME | ABOUT xCBL | xCBL4.0 | xCBL3.5 | EARLIER VERSIONS | DEVELOPMENT RESOURCES | FAQ | LINKS | CONTACT US
License Information - Copyright © 2000
For problems or questions regarding this site, contact firstname.lastname@example.org.