Technical Information Update for the XML Common Business Library (xCBL)

This issue we have a number of interesting articles and announcements. First, the latest release of xCBL, version 3.5 is now available. We are quite proud of the work that went into this version: there are nine new documents, described below, and an update to the xCBL.org website. Not only have we included the new version, but we have added a redesign of the online structure reference for easier use and better performance, and provided many new technical documents to help you in your work with xCBL. These documents are all available now at www.xCBL.org .

We are also announcing the launch of a Yahoo! Discussion Group for xCBL users, so that it will be possible for you to learn real-time from other implementers. Also, we look at how past investments in EDI can still work in an XML world, with an analysis of the significant differences, and how they affect e-business systems. Matt Fuchs, a primary designer of SOX, and Commerce One's representative to the W3C XML: Schema Working Group, provides us with a comparison of the features of the two languages. We also present an interesting case study from Schemantix, an e-business software vendor with a fascinating approach to leveraging xCBL and other schema-based XML vocabularies in creating business services. Finally, we have a review of the recent interoperability summit. All in all, quite a bit of news and information. Enjoy!

Something new! Let me draw your attention to the new xCBL Discuss forums on Yahoo. This is a public forum, for you, the user of xCBL. We have people monitoring it to answer questions, but also you will be getting answers from other users. Finding others using xCBL in similar ways or different ways, I am hoping, will be useful. In trying to find better ways to communicate with xCBL users these lists are just the start. We will be working on making it easier for you to get the information you want and need. Just remember to download xCBL or the mapping documents discussed in these forums, go to the xCBL.org website.

We chose Yahoo! Groups, because it is a free, easy-to-use email group service, that anyone with access to the Internet, has access to. Please take a moment to review the welcome message when you sign in. To learn more about the xCBL-news group, please visit http://groups.yahoo.com/group/xcbl-news

To keep up with current technical discussions about xCBL go to: http://groups.yahoo.com/group/xcbl-discuss

To see and modify all of your groups, go tohttp://groups.yahoo.com/mygroups

You are important to us. Let us have your views, comments and suggestions. As always, we welcome your feedback on the xCBL Newsletter, so please let us know if we're covering the issues that matter to you.

On December 6 7, 2001, the first meeting of the Interoperability Summit took place in Orlando Florida, and was sponsored by OMG. This Interoperability Summit Series is intended to facilitate information sharing and collaboration among standards groups that are interested in agreeing upon common models and approaches to support interoperability.

The overall objective of this initiative is to improve liaison and maximize interoperability between standards bodies, with particular regard to their project scope and working methodologies. This appears to be a laudable aim, not covered sufficiently elsewhere. The participants agreed unanimously to promote to relevant independent standards initiatives the benefits of working under the banner of an international standards organization (i.e., that their work should be recognized, monitored, and eventually published by an appropriate member of the electronic business standards MoU (e.g., UN/CEFACT, ISO, ITU, etc.) plus soon to be added, OASIS).

As a recap, the announcement of the agreement made by and between HR-XML, OASIS, OMG and XBRL during the summit. Each of the organizations agreed to:

1. Telephone conferences as necessary but at least quarterly to review potential overlaps
2. Semiannual Interoperability Summit events of the same structure, with the 2nd day focused on different technology areas each time
3. Notify each other and the Summit community of new work items
4. Liaise with each other based on new work item announcements as necessary
5. Insert into each organization's process some way to ensure that the members look at other organizations' work

Keep an eye on http://www.omg.org/interop/ or any of the sponsors' web sites for further information.

The next meeting is scheduled for June 24th through the 28th, 2002, in Orlando, Florida and will focus on procurement.

Visitors to xCBL.org will notice several new changes since our last newsletter! In November of 2001 the xCBL team announced the release of xCBL3.5. This release includes nine new documents, and some changes to existing documents from xCBL 3.0. The changes from xCBL 3.0 are strictly backward-compatible, including only the addition of new optional elements, new code values, and the change of occurrence from either "optional" to "zero-to-many", or "mandatory" to "one-to-many". (Review the xCBL 3.5 Release Notes printed below, or at www.xcbl.org/xcbl35/xcbl35releasenotes.shtml for more information.)

This month xCBL.org received a makeover. Several changes have been made to provide xCBL users with more information in an easier-to-use format. Perhaps the biggest change is a new design for the structured reference for versions 3.0 and 3.5. This new format adds improved methods of navigating the library, including a view of the current position inside the document, the addition of a users reference, and updated descriptions to many elements. It also works a lot faster when you're running it locally!

Other changes to the website include the addition of XSDL versions of xCBL 3.0 and 3.5, mappings from X12 and UN/EDIFACT for xCBL 3.0 and 3.5, structured spreadsheets of versions 3.0 and 3.5 which allow documents to be viewed in a collapsible format, and the publication of several documents to aid in implementation. To see a list of the most recent updates and improvements visit xCBL March Release Notes

With the growing emphasis on business process within the e-commerce world, we've decided to start providing more detailed information regarding the common use of xCBL (and similar) business documents from a business-process perspective. Initially available on the xCBL.org site is documentation of common exchanges for Order Management, but we have plans to publish similar material for all of the transactions supported by xCBL documents. This is not a comprehensive list, but an attempt to more completely describe the more common scenarios, so that trading partners have a standard basis for discussion.

Available now as documentation, we plan to publish the corresponding ebXML BPSS instances for these exchanges. The work is based on the ebXML work, but we have attempted to include additional needed information regarding how state is reflected in the business documents, and where other parts of collaboration are referenced from within the document. This is only an initial effort, and we would greatly appreciate your feedback.

xCBL 3.5 was released on November 19, 2001. It contains all of the documents in xCBL 3.0 and nine new documents, which are listed below by functional group. After the listing of documents you will find the Release Notes for xCBL 3.5.

ApplicationResponse: A message used by one Application (the receiver of a Business Document) to indicate to another Application (the sender of the Business Document) a business response to the received document. The document can report content errors in a document, acknowledge the receipt or successful processing of a document or can be used in those cases where a business response is needed. The ApplicationResponse document is only to be used when a specific response document does not exist for a Business Document.

InvoiceResponse: A message sent from the buyer to the seller notifying the seller that a previously sent Invoice has been accepted or rejected. This document can also respond with changes to the Invoice.

GoodsReceipt: A message initiated by the party, which received the goods. In most cases this is the buyer, but can also be a third party. The GoodsReceipt can be used to provide customary and established business and industry practice relative to the notification of receipt or formal acceptance of goods and services. The message is used to report the physical receipt of goods. It allows for the reporting of discrepancies in products, quantities, terms, packages, etc. It should not be used to convey inventory positions- this will be handled in a separate xCBL document. The GoodsReceipt is often sent when there is a discrepancy between the material being received and the information that was transmitted in the AdvanceShipmentNotice (ASN). The GoodsReceipt can also be used as a credit memo in a 'pay on ASN relationship.' In this scenario the GoodsReceipt is used as a reference for payment, as in an Evaluated Receipt Settlement (ERS).

OrderConfirmation: A message sent by the seller to the buyer to provide a confirmation on goods or services in a previously received order or orders. The OrderConfirmation can provide more specific information than was included in the Order on the specific goods and services. Multiple OrderConfirmation documents are possible for a single order and the OrderConfirmation document can be used for multiple Order documents. This document is to be sent once the services are complete.

OrderConfirmationResponse: A message sent from a buyer to a seller to confirm receipt of the OrderConfirmation. The OrderConfirmationResponse accepts or rejects the previously sent OrderConfirmation.

SourcingCreate: A message used to seek quotations using a portal-based sourcing application. The SourcingCreate document defines what goods or services are to be sourced, under what conditions the participants must respond to be considered and what elements are visible to the participants. This document contains all the information necessary for a sourcing event to be created at the portal.

SourcingCreateResponse: A message sent from the sourcing application to the initiator of the sourcing event to notify if the event was successfully started.

SourcingResult: A message sent by the sourcing application to the initiator of the sourcing event to report the results of the event and communicate the quotation information.

SourcingResultResponse: A message sent by the initiator of the sourcing event to communicate if the SourcingResult was successfully received and processed.

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

xCBL 3.5 is made up of all of the xCBL 3.0 documents, with some backward-compatible changes, and the addition of nine new documents. These changes include:

• Addition of optional elements
• Addition of new enumerated values ("codes")
• Changes of occurrence from "optional" to "zero-or-more"
• Changes of occurence from "mandatory" to "one-or-more"

The list of new documents includes:

• ApplicationResponse
• GoodsReceipt
• InvoiceResponse
• OrderConfirmation
• OrderConfirmationResponse
• SourcingCreate
• SourcingCreateResponse
• SourcingResult
• SourcingResultResponse

Note: This information is also on the www.xCBL.org website. There is also documentation about standard mappings to the corresponding ANSI X12 4010 messages and a great Structure Reference that will be a valuable tool when working with the schemas.

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: "GPSCoordinates" 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 occurrence 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.

PackageQuantity: 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.

PaymentInstructions: 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.

PersonCommunicationType: PersonCommunicationTypeCodedOther 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.

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."

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 than 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.

Every xCBL user knows the benefits that a common business language provides in achieving interoperability between trading partners. Less well-known are the huge advantages that xCBL can offer when designing and building business services. Business services are deployed to solve integration issues around a specific business process: request-for-quote, ordering, invoicing, etc. Significant business knowledge about these processes has been gathered in order to create the corresponding xCBL documents: RequestForQuote, Order, Invoice, etc. With the right tools, this knowledge can be leveraged when creating a business service that implements the corresponding business process.

A good example is user interface development. Traditionally, user interfaces contain forms (for data entry/modification) and reports (for viewing data) that web developers must painstakingly code by hand. Besides being time-consuming and error-prone, this is not an approach that lends itself well to localization or customization.

Figure 1. Invoice form generated from xCBL Invoice schema

Since xCBL describes all of the data structures needed for a wide range of business services, why not leverage these to generate user interfaces automatically? Figure 1 shows a form for creating and modifying invoices generated directly from the xCBL Invoice schema. Obviously the schema itself is not entirely sufficient for this purpose, and information about presentation (e.g. hide this field, make this field read-only, etc.) is attached to the relevant parts of the schema using a separate schema annotation file (called a schema adjunct). Creating a business service user interface thus ceases to be a long and arduous development process, and becomes more a question of tweaking the user interface that is generated by default.

The same principles apply to another major component of business service architecture: application logic. Those who have used Commerce One's XDK know that xCBL can be used to generate Java classes that ease the task of implementing business objects. Schema annotations can also be used to attach application logic to the schema: binding a formula directly to the TotalAmountPayable field of any Invoice, for instance, so it can calculate itself by adding up the subtotals of the various line items. This means that application logic can be attached to schema modules and reused across schemas and applications, regardless of programming language, deployment environment and other factors.

Finally, database-binding can also be driven using the xCBL schemas themselves. In a similar way to presentation and application logic, the database fields (tables and columns) where specific elements in the schema are to be stored can be indicated using schema annotations. Adding relational database support for a business service thus becomes a question of configuration rather than of implementing complex mapping layers on an ad hoc basis.

Traditional approaches to business service development do not take advantage of the object-oriented nature of schema languages like SOX and XSD, or the vast amount of valuable business knowledge poured into business libraries like xCBL. By using frameworks that understand xCBL natively, the task of business service development and customization can therefore be vastly simplified, leading to major benefits in terms of flexibility and time-to-deployment.

About the Author: Matthew Gertner is Chief Executive Officer of Schemantix , a Commerce One Integration Partner. Schemantix Business Service Platform is a development environment aimed specifically at companies using xCBL.

An exciting vision of business to business (B2B) Internet commerce is that of open trading communities, marketplaces, or "virtual enterprises" in which buyers and suppliers of goods and services discover each other, exchange information, conduct transactions, and seize dramatic economic benefits that would be unachievable in the "bricks and mortar" world. Some of those benefits are, significant reductions in the cost of procurement, increased revenues, shorter cycle times, lower inventories, and more timely and comprehensive information about customers and business operations. These are just some of the possible payoffs when companies exploit Internet technology for electronic commerce.

The goal of creating marketplaces, or virtual enterprises by interconnecting business systems is not new. Ideally, companies could conduct electronic commerce in a completely ad hoc fashion, without prior agreement of any kind, and proposals for "Open EDI" and "Plug and Play Commerce" on the Internet predate the XML groundswell of the past few years. But prior to XML, the technology foundations for this vision of electronic commerce simply weren't capable of making it happen. A new approach was needed - enter XML!

XML is rapidly becoming the enabling technology for Internet markets and connecting with existing EDI trading communities thereby recognizing the value of preserving EDI's years of experience in designing messages that meet business process requirements. But the ease with which anyone can invent new XML models for particular industries or subject areas is both a primary attraction and a significant threat to the interoperability of messages within and between trading communities. Other challenges include the need for business exchange documents to be customized for a particular trading community while still being understood and interoperable with documents in other communities.

A major step toward the creation of electronic trading communities took place in the late 1980s with the emergence of Value Added Networks (VANs). These VAN's acted as intermediaries that enabled the growth of EDI trading communities. Twenty years of EDI experience has created X12 and UN/EDIFACT standards for a few hundred transaction sets and messages in many different industries and application areas. So at first glance it might seem that traditional EDI could be quickly adapted to the Internet in order to obtain lower costs and faster message delivery. Whilst this gives the impression that integration of EDI-enabled functions with other Web services could be simplified, in practice, traditional EDI will not make the transition to the Internet or XML any easier.

Because it is viewed by many as a "smarter HTML" XML is heading toward HTML's ubiquity, while overcoming HTML's inability to encode content in meaningful ways. At the same time, XML is exploiting the twenty year old promise of EDI to focus on the documents that businesses exchange to request and perform services, while sidestepping some of the limitations deriving from EDI's syntactic rigidity. Major database, ERP, and "sell-side" software vendors are building their latest generation software on a native XML platform and are developing common interfaces that let businesses easily integrate with external XML formatted information. Defining interfaces in terms of XML documents also allows for an incremental path to business automation, whereby browser-based tasks are gradually transferred to computer processes. A supplier with a small product catalog and a hand full of sales each day can use a web browser to receive and send order acknowledgments until such time that increased transaction volumes justify integration with ERP or other database applications.

Unfortunately the ease with which XML business documents can be designed and implemented has resulted in an even greater and more rapid proliferation of XML document structures than there are for traditional EDI. These are defined by individual trading partners as well as by vertical and horizontal business communities. For example there are already estimated to be several hundreds of different Purchase Order XML document definitions in existence today.

So does this mean we don't like it? Many have interpreted these as signs that "EDI is dead" -- made completely obsolete by the XML upstart -- but this view is naive from both technical and business standpoints. Companies with large investments in EDI integration will not abandon them without good reason. If, and probably more importantly when, they decide to take advantage of the capabilities offered by XML, they will try to preserve as much of those investments as they can. However, transforming EDI to XML is not straightforward and some hard technical problems must be overcome. A better long-term solution is offered by recent initiatives to define a common set of global business semantics, which if adopted, can ensure interoperability across syntaxes, industries and borders.

In 1999 the EDI and XML communities came together in an initiative to determine "the technical basis upon which the global implementation of XML can be standardized" for electronic commerce. This initiative, called ebXML, was jointly announced by UN/CEFACT and OASIS in September, 1999. It will develop globally agreed syntax-independent business process models, together with semantics definitions which will enable the development of syntax specific message design guidelines that will harmonize EDI and XML document architectures. Too many it will, which will's in this sentence!! Also the sentence needs to be shorter.

The ebXML initiative has great promise. It is both the first XML standardization activity (begun by a global EDI standards body) and the first attempt by the EDI standards community to work with XML experts as equal partners in shaping the transformation of EDI to XML. If ebXML succeeds in attracting participation from a critical mass of the XML specifications currently proposed, or indeed currently under development, it will speed their convergence to interoperable architectures. In addition ebXML opens the way for a new generation of traditional EDI message definitions which will interoperate with ebXML compliant document structures.

But even if ebXML or any of the numerous XML specifications were to be widely adopted as the standard business documents, large challenges remain for XML trading communities. Documents defined for a community will not be fixed; rather they will constantly evolve due to changes in regulations, business processes, service offerings etc. This fast paced change will be the hallmark of future business and its support will be a necessity for future success of electronic commerce systems.

XML DTDs are somewhat limited and inflexible in their support for controlled customization and extensibility. If a DTD must be changed after the fact to allow for unanticipated customizations, all of the applications relying on the original DTD must also be changed, even if they don't need the customizations. Most XML architects working on Internet markets and trading communities are hopeful that XML Schemas will be the technical magic that enables documents to be customized for a particular trading community while preserving the interoperability with other communities. The recently ratified W3C recommendation for XML Schemas, XSDL, offers standardized schema extension mechanisms which will allow a community to define base documents that can be extended to meet the customization needs for some trading relationships while maintaining the ability to ignore those extensions in other relationships or communities where they are not needed.

There have been many questions to the xCBL support team about SOX and XSDL. How they match and what is what. Here is a brief outline from Matt Fuchs about what was submitted and those features that were, and were not, implemented. There is of course a debate going through the business community about how to make it work. XSDL seems to allow much ambiguity in implementation, the fear here being that no one will use it the same. This is always a worry when trying to build systems that can interoperate with other systems. Read on and judge for yourself. SOX was initially submitted to the W3C as a note in 9/98. SOX 2.0, the version discussed here, was submitted in 1999, and members of the SOX team have been heavily involved in the development of XSDL. Among SOX innovations found in XSDL are:

• Polymorphic documents.
• The extension mechanism.
• The SOX modularity mechanisms (the SOX namespace and join elements show up in XSDL as import and include).
• The separation between a schema and its XML representation is an important feature of SOX taken up by XSDL. XSDL explicitly describes its abstract components, while the component model for SOX has not been made public.
• Use of locally scoped elements.
• User defined datatypes.
• Restrictive refinement for user defined datatypes.
• Rejection of parameter entities.
• First class attribute and model groups (present in SOX 1.0 but not implemented in 2.0)
• Identification of a schema with its namespace.

XSDL has a few features not implemented in SOX:

• A restrictive refinement model not implemented in SOX, however some of our early explorations along those lines were initial input to the XSDL process.
• Mixed content.
• Regular expression patterns for datatypes.
• Keys and keyrefs.

Going through the questions we receive each month, I have tried to find issues that pertain to more than one user. I hope in this collection of questions and answers you find something that helps. Feel free to contact us with your questions at xCBL.

Should I use xCBL or cXML?

There are several differences between xCBL and cXML, mostly that they are designed to do different things. Both cover basic e-procurement scenarios, although cXML uses a "Punch Out" mechanism that relies on the buyer going to a supplier website and generating an Order Request that is then sent to a buying application that generates a Purchase Order.

xCBL has these documents (in xCBL 3.0 and xCBL 3.5) but also allows you to use a more traditional approach that skips the order-request stage. In addition, xCBL covers a lot more of the auction, sourcing, collaborative planning, payment, and shipping documents than cXML does. Also, xCBL is available in many schema language formats, while cXML is only available as DTDs.

Ariba - the people who created cXML - recently announced that they would be supporting xCBL, but you may have to contact them to find out which documents they will be supporting.

As for mapping between the two, I would recommend looking at technologies based around XSLT, since this seems to be the way most technology vendors are doing this. If you take the DTD-based version of xCBL, and cXML, you could use things like the Apache Foundation's free open-source parser Xerces, and their XSLT engine Xalan. There are many good books available now on XSLT, and probably some good resources on the Web.

Some customers have done mappings between corresponding documents in the two vocabularies, so we know that it can be effectively done.

I need more information about the routing envelopes that may be used with xCBL, since I haven't seen one specified in the xCBL.org site. Will you support the use of an xCBL-formatted payload within a BizTalk or ebXML (when it's released) envelope?

xCBL is envelope-agnostic. This means that it can be used with any enveloping mechanism, since it does not contain the enveloping information inside the message payload. At the request of some people supporting legacy EDI systems, we have included a set of optional envelope-fields as attributes on the root of every document on xCBL 3.5, but these are really there so that a recipient could get the message, copy the enveloping fields into the payload, and then pass it off to a translation engine that will now have the required information to populate ISA fields or other control fields. These attributes are not meant to be used for the actual delivery of the message - the envelope - whatever you use - should take care of that.

I need error handling information for Purchase Orders. The documentation from the xcbl.org site references error codes in "another document", but I cannot find this other document.

For xCBL 2.0, there was a publication called the "Interconnectivity Guide" that gave all of the error codes. The xCBL team is not responsible for error codes, since these are specific to the applications that use xCBL (not all of which are from Commerce One!). I would suggest that you get in touch with Commerce One support, and ask them how to get a hold of the latest documentation for the products you are working with, as this should contain the correct error codes. If you are working with a non-Commerce One product, try contacting their support people for the documentation that contains error codes.

What: UN/CEFACT EWG Meeting aligned with UBL meeting at same place.

When: March 18 - 22, 2002

Where: World Trade Centre, Port of Barcelona, Spain

Special Note: To find out more informaton about this meeting, go to: http://www.unece.org/cefact/

What: OASIS UBL TC Meeting aligned with EWG meeting.

When: March 18 - 22, 2002

Where: World Trade Centre, Port of Barcelona, Spain

Special Note: To find out more informaton about this meeting, go to: http://www.oasis-open.org/committees/ubl/

What: Down To Business: Getting Serious About XML

When: May 19 - 24, 2002

Where: Princesa Sofia Inter-Continental, Barcelona, Spain

For more information go to: http://www.xmleurope.com/

In its 19th year as the premiere European Markup Technologies Conference Exposition, this event will continue to serve as an exchange of information forum, bringing companies to new heights within the industry.

What: Interoperability Summit sponsored by OMG

When: June 27-28, 2002

Where: Caribe Royale in Orlando, FL

More info to come. In the meantime, check out http://www.omg.org/interop/

When: August 4 - 9, 2002

Where: Hotel Wyndham Montreal, Montreal, Canada

Notes: Tutorials and Conference. "Extreme Markup Languages brings together software developers, markup theorists, information visionaries, and other assorted geeks for formal presentations, poster sessions, question and answer sessions, hallway discussions, arguments... participants include thought leaders from corporate and academic information management, knowledge engineering, enterprise integration/corporate memory, science, and technical and cultural research."

What: UN/CEFACT EWG Meeting aligned with UBL meeting at same place.

When: September 16 - 20, 2002

Where: Guatemala, South America

Special Note: To find out more informaton about this meeting, go to: http://www.unece.org/cefact/

The xCBL User's Group Newsletter is produced using XML. If you would prefer to receive it in raw form, drop us a line.

Co-Editors: Arofan Gregory, Lisa Seaburg, and Gordon Watt

Designer: Lisa Seaburg

Contributors: Arofan Gregory, Lisa Seaburg, Sue Probert, Valerie Ziegler, Jack Gager, David Burdett, Matthew Gertner (and a great group of proof-readers!)