|
![[]](/images/x-join.gif){kind=small} |
|
 |
 |
Technical Information Update for the XML Common Business Library (xCBL)If you wish to print this newsletter please make sure you do so in landscape format.
This issue of the xCBL Newsletter has finally arrived. We have been patiently waiting to put this issue out, but for the best of reasons: the xCBL staff has been busy creating a major release (see next article). While it will not surprise developers who have been working with xCBL 2.0, being in many ways consistent, the new xCBL 3.0 version is quite different in its basic design goals. Consequently, this issue of the xCBL Newsletter is largely devoted to giving xCBL users a look at what is coming. The initial release of xCBL 3.0 will occur in December; and the press release was issued on November 29 at eLink Hong Kong. But it's not the press release we care about - it's knowing what the new documents are, what they look like, and how they will impact our e-commerce applications. This issue of the newsletter will contain articles not only about what xCBL 3.0 is, and what it is intended to make possible from a design standpoint, but will also address the methodology we have been using to create new documents, and that we recommend to our users for doing their own development with the xCBL component libraries. It also positions xCBL in terms of UDDI, an interesting - although not competing - standard in the e-commerce space. Altogether, I think the xCBL user community should find this issue of the newsletter to be of interest. Oh - and, before I forget - happy holidays! (Assuming they don't make you work the whole time...)
In the June issue of the xCBL User's Group Newsletter, it was announced that we would be doing a number of additional point releases to include new document types and bug fixes in xCBL. We reviewed the existing fixes and new documents, and considered the many requests for documents that would be needed to offer meaningful support for direct goods scenarios, ERP integrations, and to support standards such as RosettaNet and OBI. It was determined that a major release was needed, rather than a series of minor releases. Consequently, we will be releasing xCBL version 3.0 in December of 2000. This release represents a fundamental change in the design of xCBL. In this article we will present the business documents that will be covered under this release, and describe the other supporting information that will be released to make xCBL 3.0 more usable, and more conducive to broad-based interoperability, than preceding versions.
xCBL version 3.0 is different than the preceding versions in one major respect: instead of being a single, extensible set of documents for doing Order Management, it has become a wide-ranging set of messages intended to provide interoperability across a broader range of direct goods and procurement scenarios. It has been designed to provide support for a number of existing standards, among which are:
Also included in the analysis were a number of Payment Standards, EDI implementation for utilities, energy, and telecommunications, and foreign trade implementations. This support takes the form of being able to unambiguously specify how data will map into and out of each of these standard formats. Thus, while xCBL 3.0 becomes an over-arching standard like X12 or UN/EDIFACT, it avoids the problems of having multiple places to put a single piece of data, leading to ambiguity in specifying how an application is expected to handle any given field, or confusion about which fields require support. Official mappings for all of these formats will be published at the time of the xCBL 3.0 release, or soon after, to make it easier to guarantee interoperability between trading partners using different message-definition formats (see below). Other major design drivers include ERP data structures, typical transaction choreographies and the data limitations imposed by existing back-office systems, the requirements of "gateway" architectures to support trading partners using different standards for doing business, and the forward-looking design of ebXML. This last point requires some comment: ebXML has not yet finished its work of defining "core" components and the extension methodology that will be used with them, making it impossible to provide an "ebXML-compliant" xCBL 3.0 at this time. xCBL staff has been heavily involved in this effort, however, with the intention of providing an ebXML-compliant xCBL as soon as this is feasibly possible. Some of the existing design is pointed intentionally toward this goal.
The following is a list of message definitions appearing in xCBL 3.0, indicating the functional areas covered. Each is described briefly. Catalog Content
Order Management:
Invoicing and Payment
Materials Management (Shipping and Planning)
Statistics and Forecasting
Trading Partner Documents
Auction, Availability, and RFQ Documents
Synchronous Checks (MRO)
Miscellaneous
Note that xCBL 3.0 exists entirely within its own namespace, and has no backward-facing dependency on xCBL 2.0. This is in keeping with the xCBL definitions of a major release versus a minor one: xCBL 3.0 supports all of the data fields in corresponding xCBL 2.0 documents, but does not provide backward compatibility (nor require the availability of xCBL 2.0 definitions) for a major release.
xCBL 3.0 will be released on the xCBL.org web site, with the following resources for each message definition:
Additionally, we will be publishing two Application Profiles. These serve to guarantee interoperable support among those xCBL-supporting applications that do lighter-weight e-procurement. Note that these profiles also serve as reference points for those trading communities that have "non-standard" needs, and must extend one or the other of these basic profiles.
[Note that W3C Schema material will be made available shortly.] Further, mappings between each document in xCBL 3.0 and the corresponding document in xCBL 2.0 will be provided.
xCBL 3.0 represents a new milestone in establishing a full-featured, standard set of XML messages and the components which comprise them. We fully anticipate that these new message definitions will meet the needs of a far wider variety of applications and functions for e-commerce, and that they will serve to enhance the potential capabilities of xCBL-based exchanges and applications. We have learned a great deal in creating, maintaining, and implementing xCBL thus far, and we are confident that xCBL 3.0 will show how much we have benefited from the input of users everywhere.
Universal Discovery, Description and Integration (UDDI) is a new standards initiative that is designed to facilitate the discovery and integration of businesses on the web. It supports discovery by holding in a repository on the web, information about: businesses, the "services" they offer, and how to connect to them. A service could be, for example, an Order Management service, which can accept purchase orders or a payment gateway through which a payment could be made. The description of how to connect to a service that will support multiple methods of connection. It could be something as simple as a telephone or fax number, the URL of a web page, or, more interesting, the URL of a web based service to which you can post documents that conform to a specified protocol. This is where xCBL will fit in, as an xCBL PurchaseOrder could be posted to the URL if that is what the UDDI registry has recorded as what it could accept. It could also be, for example, a web service that accepts RosettaNet, OBI or EDI. Another interesting aspect of UDDI is the agreement amongst the initial operators - including Sun, Microsoft, IBM, Ariba, i2, Commerce One and others - to operate registries that hold this information and then share the information with each other. This means that you can go to any one UDDI registry and access the information that is held at all of them. Technically UDDI is built on top of SOAP and uses XML documents to register and query information. .
XML has the potential to enable a standards-conforming, open, and extensible architecture for electronic commerce. Additionally, XML and related standards can enable ubiquitous connectivity and interoperability. This ubiquitous interoperability enables the network effects of "describe once and transact anywhere" with reusable electronic business services. This vision depends on creating standards not only in the definition of data structures, but also the way in which these data structures relate to the business processes they enable. This is an issue that is receiving much attention in the world of technology standards today. Commerce One is an example of a company that has built the electronic commerce marketplace to support this kind of connectivity and interoperability. Furthermore, Commerce One actively participates in a number of standards efforts, including those of the W3C and, perhaps most important, ebXML. This article is the first part of a series that describes how xCBL has been designed to align with the vision of freely interoperable business services, and how that design has its roots in the business services framework. Business services are the software components that exchange electronic documents in an electronic marketplace. These business services interoperate because they share a common semantic framework based on documents. They can be linked to create virtual companies, markets, and trading communities. Commerce One, its partners, and third parties want to build new business services to extend the current electronic marketplace offerings thereby generating revenue for electronic marketplace operators and service providers. Commerce One's document-based service framework allows for its partners and other parties to rapidly develop and deploy XML document-based business services. While the service framework provides the technical foundation for interoperability, it does not address the issues associated with the up-front analysis and design efforts. For example, there are a number of e-Marketplace portals, including Commerce One, with interests in financial documents and related business processes. Without coordination of these efforts, the world community could end up with similar-but-different financial documents and business processes. While this may be acceptable for any given electronic marketplace, interoperability with the greater world-wide electronic marketplace is lost. Trading partners and service providers will find themselves re-implementing interfaces to their systems to support documents that could have otherwise been identical.
A business process specification methodology and coordination process is needed to address these issues. The methodology and process needs to provide the following:
The xCBL team worked to create such a methodology for the xCBL 3.0 revision. It involves basing the entire set of data issues in perspective by first understanding the common patterns of document exchange within the business process, identifying the documents involved, the functional pieces of information they carry, and the meta-data requirements of the services architecture. Such questions as: "Is this a synchronous or asynchronous process?" are fairly obvious, but not all the issues are so simple. When you get into questions of how to promote interoperability using extensions, and how those patterns relate to the ease of building business services based on the data contained in a response document, the issues require more thought. In creating the latest version of xCBL 3.0, this methodology has been followed, starting with the services developers in as wide a range of applications as could be found, and working from the proposed document exchanges for those services to a definition of the standard data formats that are encoded in the xCBL 3.0 schemas. This methodology has also been proposed as the basis of the Global Trading Web document-creation methodology, and has been taken as input by the ebXML working groups focused on Core Components and Business Process. In subsequent xCBL newsletters, the specification methodology and coordination process will be detailed further, in hopes that xCBL users will at least have a basic model on which to base the evaluation and analysis of the services which they are developing, and to create documents from the xCBL component library that have a consistent and sound connection to the processes which they enable. Topics will include:
This section addresses the usage of some of the common elements in xCBL. This month we are discussing lists of codes that come from outside sources or enumerated lists. (If you have a question on usage, please send mail to xcbl@commerceone.com . We will answer commonly asked questions in the newsletter.) This month I have listed out some of the more common enumerated code lists. In coming months we will be making these code lists available on the www.xCBL.org web site. These lists have been compiled by experts with the XML/EDI/EDIFACT/ISO fields. They were not written by Commerce One employees but have been compiled by them. The Document Engineers working on putting together xCBL 3.0 have the experiences of xCBL 2.0 and the first version of code lists to go on, and have also worked with experts on the international code lists in developing the versions supported by xCBL 3.0.
Codes are used to provide an unambiguous definition of data. Without this almost limitless definitions of the same data can appear proving impossible to be processed. Think how many different, common ways there are of representing the United States: "US", "USA", "US of A", "America", "U.S.", "U.S.A.", etc. The code lists used by xCBL30 fall into three categories:
In all code lists there is a facility to allow a textual description for the definition of undefined codes. The basic approach taken by the designers of xCBL toward codelists is to used "intuitive," spelled-out abbreviations, rather than shorter alpha-numerics, wherever possible. This decision does not apply to such lists as the currency and language codes, which are internationally used, but applies in most other cases. One of the reasons for this design decision was that, in many cases, different standards bodies had used the same alpha-numerics to indicate different things within code lists that performed the same function. (Plus, they're easier to read when you spell them out!)
The Language Code datatype enumerates the codes that may be used to specify language name. The codes are based on ISO 639-1988 "Codes for the Representation of Names of Languages," specified by UN/EDIFACT (D.99B) element 3453, language name code. To view the entire list go to: LanguageCode Code List For more information, visit the UN/ CEFACT (UN/ ECE) web site at http://www.unece.org/cefact or the UN/EDIFACT web site at http://www.unece.org/trade/untdid/welcome.htm Using the element Language is similar to Currency in that you make a choice from an enumerated list, (type: LangCode). These codes are lower case and two letters. Here is a sample: Language Code
There are more than 50 code lists in CBL 2.0. and, are something like 90 in xCBL 3.0. We will be making the code lists available on the web site after the first of the year. Watch for them!
Geek Cruises, XML Excursion 2001If you feel the urge to hang out with even more serious geeks than you do at work, you might consider this event, co-hosted by OASIS. (I hear some of the most serious XML geeks on the planet are actually joining this one - a frightening thought, to say the least... The line-up of speakers includes a comprehensive list of heavyweights! Just imagine - pool-side chats to discuss the return of OMITTAG and SHORTREF to XML, and I'm sure that will be the least of it...) When: Jan 26 - Feb 5, 2001 Where: Aboard Holland America's Volendan , in the sunny, Southern Caribbean For more info: http://www.geekcruises.com/ AIAG - EDI/XML Project Team MeetingAIAG has been very involved in defining a solid industry sub-standard of X12 for use within the Automotive vertical, and they have been aggressively involved in ebXML and other XML-related standards efforts. When: January 18, 2001 Where: Detroit, MI For more info: http://www.aiag.org/calendar/index.html ebXMLThe ebXML work continues (more on this next issue!). We encourage everyone who cares about xCBL to get involved! When: Feb 12 - 16, 2001 Where: Vancouver, British Columbia, Canada For more info: http://www.ebXML.org Accredited Standards Committee X12 Trimester MeetingX12 is the major player in EDI standards definition in the US, and it is becoming more involved in XML-related activities. When: Feb 4 - 9, 2001 Where: Seattle, WA FOR MORE INFO: http://www.x12.org XML DevCon Europe 2001When: Feb 21 - 23, 2001 Where: West London, UK For more info: http://www.xmldevcon2001.com UN/EDIFACT Working Group (EWG)EWG has had heavy involvement in the Core Components work at ebXML, and these meetings are recommended for those interested in global B2B standardization. When: Mar 19 - 23, 2001 Where: Washington, D.C. For more info: Contact Gaile Spadin or go to the web site. ebXML (Interim Meeting)To guarantee completion, ebXML has decided to have an interim meeting, before the May meeting in Vienna. When: March 26 - 30, 2001 Where: Geneva, Switzerland For more info: http://www.ebxml.org XML 2000The pre-eminent XML conference in the US (at least judging by its history - this is the direct descendent of the old SGML conferences, and is still very worthwhile attending for those interested in XML and related technologies, whether on a business level or a technical one.) xCBL staff will be presenting, both during the pre-conference tutorials ("XML and Electronic Commerce") and during the conference ("Role of Extensible, Polymorphic Schema Language for Electronic Commerce Communities" by Matthew Fuchs, one of the creators of the SOX Schema language). When: December 3-7, 2000 (Pre-Conference Tutorials/Special Interest Days: December 3-4, 2000. Tracks on December 5-8, 2000) Where: Marriott Wardman Park, Washington, DC For more info: http://www.gca.org
When you are looking for general information about xCBL and related XML technology. The SOX Tutorial (PDF) will help you understand the workings of SOX. It's a great place to start when trying to learn about the XML schema and how it works and how to write your own. Reading the existing schema will also be easier if you start here. XDK (XML Developer Kit) (includes CXP, the SOX Parser, and an integrated XSL transformation engine). I use the CXP parser when working with the schema. In the near future we have a GUI version that will be available through the xCBL web site. At the moment the Documentation available includes the Document Guide (WARNING: Large file size!) - this is also available in downloadable form.) This documentation goes into the workings of CBL 2.0 - we are furiously working on an On-line Reference Guide that will be released with xCBL 3.0. In trying to make the documentation easier to use, we have also tried to come up with the information that you need. Please use the xcbl@commerceone.com email address to write in with questions or comments about your work with xCBL.
The xCBL web site will give you lots of information about xCBL and the XML technology that Commerce One uses. There are FAQ pages, Download pages and Documentation pages. Check it out!
There is BizTalk (you must register with the BizTalk repository before getting access). You can also download xCBL from the BizTalk Repository. Background: Biztalk was launched in March 1999 by Microsoft and involves a wide range of technology vendors and technology users. It is not a standards' body, rather it is a community which is focused on creating the environment which will allow the 'best man to win'. The Biztalk framework consists of a set of guidelines for the publication of XML schemas, such as purchase orders, etc., and on how best to integrate these with existing and future applications. XML schemas are structured XML message format definitions. Currently there exists more than one type of XML schema (XDR and SOX are the most common) and the completion of a global schema standard is urgently awaited. The Biztalk framework also includes an enveloping framework and a repository into which anyone's schemas (XDR format) may be stored. Update: Microsoft continues to pursue its own strategy and the list of Biztalk partners and B2B potential customers continues to grow. However, Biztalk still shows no signs that it is intending to tackle any interoperability at the data semantic level. The Biztalk framework is one of the cornerstones of the work of the ebXML Transport, Routing, and Packaging Project Team.
(www.rosettanet.org)Background: The RosettaNet initiative started in the middle of 1999 and is based on its own community modelling of the IT and electronics supply chain. RosettaNet therefore has a strong electronics industry focus and its members are the major computer manufacturers and their suppliers including Compaq, CISCO, HP, IBM, Intel, Toshiba, Microsoft, ORACLE, SAP, etc. RosettaNet started out as highly influenced by the ANSI X12 message formats but has recently started to break out of this mould as it has begun to realize the strengths and benefits of the XML syntax. RosettaNet is building, promoting and implementing standardized business process data exchanges within the IT supply chain. Update: The RosettaNet business models have been contributed to the ebXML Business Process Modelling Project Team's reference material. Both RosettaNet and EDIFICE are participating in ebXML thereby widely representing the electronics industry sector and bringing in a great deal of practical XML for business knowledge.
(www.oasis-open.org)One great place to go is Robin Cover's OASIS SGML/XML Web Page Great place to find all kinds of information. OASIS (a not-for-profit organization made up of the major software vendors in the XML/EDI arena). The first version of xCBL is also available through the XML.org repository.
(www.ebxml.org)Background: ebXML is a global standards initiative for XML/EDI launched in September 1999 by UN/CEFACT in conjunction with OASIS. Its mission is to create a Single Global Electronic Market\#8482; by providing an open XML-based infrastructure which enables the global use of electronic business information in an interoperable, secure and consistent manner by all parties. It has set itself a challenging target for completion of the first version of the ebXML framework within eighteen months of its launch. So far, two meetings have taken place and eight project teams have been set up to work in parallel. Standards Bodies represented: UN/CEFACT (TMWG - Techniques & Methodology + BPAWG - Business Process Analysis + EWG - EDIFACT + CDWG - Codes Working Groups) OASIS, W3C & eCo Framework ISO: TC154 + TC154/WG1 BSR(3) & TC68 OMG (Object Management Group) CEN/ISSS - European XML/EDI & DAMSAD - Data Harmonization Workshops
(www.w3.org)When looking for XML Schema information the w3c may be a good place to start. Background: World Wide Web Consortium or W3C. Find information about Namespaces in XML at this link. The Mission of ebXML is to provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties. Go to this link to find out more: ebXML There are several organizations that may prove helpful when doing research into EDI-to-XML issues. You can try DISA or Data Interchange Standards Association and the related ASC X12. Also, see the UN/CEFACT links above.
We are interested in hiring people with an interest in B2B e-commerce, and a background in SGML/XML and related technologies. Please send resumes and/or questions to: xcbl@commerceone.com .
Subscription to this newsletter is through Commerce One. To subscribe or unsubscribe, please send an email to: xcbl-list@commerceone.com. Include your name, company name, and address along with your email address. Use the phrase "xCBL Mailing List" in the subject field, followed by the phrase "Subscribe" or "Unsubscribe".
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 Designer's: Lisa Seaburg, Stuart Bee, Chris Probert Contributors: Brian Hayes, Arofan Gregory, Lisa Seaburg, Sue Probert, Bob Glushko, Karen Walters, Jean McInerney, Matthew Fuchs, Murray Malone, David Burdett, Valerie Ziegler |