|
![[]](/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.
If you work on the xCBL team, you will see lots of e-mail coming from users who ask questions about various technical details, and have no doubt done your share of replying to these e-mails. If you are an xCBL user, you may well have written to us with questions, and (hopefully) received a well-informed and timely reply. But it's not often that we get the sort of e-mail (name suppressed - presumably you know who you are, and we don't want to embarrass you!) that we reprint here: Dear xCBL'ers, Thanks for all the great work, the quality of the DTD modules and accompanying documentation is a joy to use. What else can you say? It's e-mail like this (and, well, maybe - sometimes - the paycheck) that keeps us going... On a more serious note, I recently found a book at the local Border's that not only makes sense out of a lot of the complexity around XML in the B2B space, but has an entire chapter about xCBL! The book is Building B2B Applications with XML: A Resource Guide , written by Michael Fitzgerald for Wiley, and it's just out - the copyright date is 2001. (For those who might need it, the ISBN is 0-471-40401-2.) Fitzgerald will apparently be publishing two other books in the same area soon - one about XML Schema, and the other about XSL. If they are anything like this book, they will no doubt prove very useful. This book is not incredibly technical, so it may not be the place to get snippets of code from, but it provides an awful lot of explanation about how all the various XML-based pieces of the puzzle fit together, and it gives lots of good places to go for more technical information. It discusses the overall problem space, and gives lots of detail on ebXML, xCBL, cXML, BizTalk, and SOAP, among many other things. (Finally, you'll know what all those acronyms stand for!) Rather than review the entire book, I'll suggest that you go to the bookstore and check it out for yourself. The review of xCBL seems to us to be quite fair in most respects. The author does raise a few points about xCBL that I would like to take the time to clarify, however, as these may be questions that other people wonder about as well. The first of these is simple: Why does Commerce One bother to create and distribute xCBL? The author says nothing more than presumably Commerce One gets some benefit from it. Actually, there is a very good answer, and one that is non-obvious. Commerce One has a business model that is not much like those of other software companies: rather than making money simply on license sales and consulting money, like most solutions companies, Commerce One has a model that derives money from transaction flow. What this means, in brief, is that the more different software applications connect to Commerce One marketplaces, the more money the company makes. If our competitor's products can connect to our marketplaces, we still make money, and so do our partners who operate portals. If you think about it, it's a bit like a telephone company: they make money off of the infrastructure - how many calls you make - and not the sale of telephones. Commerce One is an infrastructure company, and not - primarily - an applications company. The important part of this from a user's perspective is that it allows Commerce One to create and support the use of open standards. That is what will allow the largest number of trading partners to get connected the fastest, and thus increase the transaction flow. We all know that standardization in this space is complex, but ultimately Commerce One's business model allows us to work toward finding a solution to a complex problem, and to do it in a way that benefits our software customers and other B2B application developers at the same time. The second point that Fitzgerald raises in his book - and doesn't really have an answer for - is the use of elements rather than attributes. To quote: One other thing of interest to note is that xCBL uses relatively few attributes compared to the number of elements. I believe this is strictly a matter of preference. Actually, there is a method behind this madness. It results directly from the fact that xCBL is the only business vocabulary available today that uses an XML Schema language to enable the use of (additive) extensions. If you use XDR or DTDs, you do not have the capability to resolve extensions at run-time: either the application "knows about" a tag, and has integrated to it, or it doesn't. This means that everyone in a trading community has to have integrated to exactly the same document type. If you are using xCBL in SOX schema form (and the XDK), then you can do a little better. You can extend known element types to include extra data. The receiving application can choose to either process the full set of tags, or - if the extra data is not important - it can process the document in its standard, un-extended form. This aspect of xCBL is complex, resulting from the object-oriented features of SOX, which are also to be found (among many others) in the W3C Schema language. (For more information, go to xCBL.org and take a look at the SOX Tutorial.) What this does require, however, is that the XML schemas be designed for extension. The simple fact is, you cannot extend attributes - they have no substructure. In xCBL, we know that sometimes our users will want to leverage run-time extensions to promote interoperability. The result of this is that we have used elements in most cases. (If you want to accuse us of looking forward to a W3C XML Schema version of xCBL, feel free!) There are a couple of other minor points that could be raised, but buy the book and see for yourself. If you still have questions, send us an e-mail, and we'll try to respond in a helpful and timely way...
This section covers some late-breaking additions to xCBL 3.0, as well as providing a list of known bugs, and discussing some issues that have caused much discussion among the xCBL user community.
This second release of xCBL 3.0 includes new business documents along with some fixes. We are always working to improve and build upon this set of business documents (and soon we will have an xCBL version 3.5 to add several more, including the much-wanted Goods Receipt...). With this release, we have made more modest additions:
These documents are included in the xCBL 3.0 namespace, and are available in all the usual formats from xCBL.org. In addition to the new documents, two bugs from the December release have been corrected:
Other bugs will be fixed in upcoming version releases.
The following is a list of known bugs in xCBL 3.0, release 2 that you should be aware of, along with some explanations on how to use elements that are fairly complex, and require specific attention.
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 an entry in the ListOfMessageID with an "AccountOf" code indicates to the application that this field should be examined.
ASNPartialOrderCode will have its name changed to "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 also possible to define the quantity contained within a package at the item level. This can be achieved by using the Quantity child element of the PackageReference element within the item.
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".
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).
There was much debate during the design of xCBL about the restriction of field lengths to support interoperability. The following ideas were 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.
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.
The Commerce One xCBL Certification Program is designed to assist content solution and services providers to demonstrate their ability to publish electronic content in the Commerce One xCBL content exchange standard. xCBL Certification Program Members can market their content solutions as xCBL Certified, making their solutions more attractive to the growing community of Commerce One customers around the world, and making it clear that they will interoperate with other xCBL-based applications. By becoming an xCBL Certification Program Member and successfully completing the program requirements, you will earn the right to promote your company's solutions as being xCBL Certified. This designation can help you attain greater marketability for your solutions within the Commerce One B2B e-commerce "ecosystem," or any community that uses the xCBL ProductCatalog for its exchange of catalog data. We intend to expand the certification program in the future. If you want more information or have any questions contact the xCBL Certification Team.
As mentioned in XML Business Process Specification Methodology Part 1 , the xCBL team and other Commerce One employees have been very active in various ebXML activities, including those in the area of business process and business information analysis. ebXML specifications and supporting documents in all areas are now available for review and public comment at the ebXML . We have listed the documents related to business process analysis and specification with a brief summary below. You are encouraged to read and comment on them! They are available at the ebXML Business Process Project Team website.
Business Process and Business Information Analysis Overview This document deals with aspects of commercial interoperability, specifically the process by which enterprises can analyze, identify, and define those business processes and business documents necessary for the conduct of electronic business with other enterprises, within the ebXML framework. The audience for this document will typically comprise representatives of any of a number of different functional areas within an enterprise, including marketing, business development, executive management, procurement, software development, IT, etc. Business Process Analysis Worksheets This document contains several worksheets that guide analysts in the creation of business process specifications of that are compliant with the UN/CEFACT Modeling Methodology and its e-Business Process Metamodel. The worksheets and guidelines are for users regardless of whether they are working on behalf of a standards body or an individual company. A variety of scenarios guiding how one might go about filling out these worksheets (e.g. top-down vs. bottom up) is provided. E-Commerce and Simple Negotiation Patterns This document discusses a simple e-commerce collaboration pattern for a legally binding negotiation. ebXML Catalog of Common Business Processes This document puts together an initial list of common business process names, generic in nature that can be used across various industries. This includes business processes with cross references across common industry standards; including RosettaNet PIPs, X12, EDIFACT, JiPDEC/CII(Center for information of Industry of JAPAN Information Processing Development Center), OAG BOD, xCBL (CommerceOne). Identification of this catalog of common business processes were influenced by various industry initiatives like RosettaNet , EIDX, CPFR , EIAJ, OAG etc. This document also describes how to catalog business processes. The target audiences for this document includes business staff of both information and technical background and specific business focus areas wishing to relate their electronic trading activities in a consistent pattern to the general ebXML trading community. ebXML Business Process Specification Schema The ebXML Specification Schema provides for the nominal set of specification elements necessary to specify collaboration between business partners, and to provide configuration parameters for the partners' runtime systems in order to execute that collaboration between a set of e-business software components. The ebXML Specification Schema provides a standard framework by which business systems may be configured to support execution of business collaborations consisting of business transactions. It is based upon prior UN/CEFACT work, specifically the metamodel behind the UN/CEFACT Unified Modeling Methodology (UMM) defined in the N90 specification. The Specification Schema supports the specification of Business Transactions and the choreography of Business Transactions into Business Collaborations.
For this issue of the newsletter, we went through the questions that developers have sent to us and picked out some of the ones that get asked over and over again. We reproduce some of these here, to help answer questions before they show up in our inbox! We have also given a pointer to a "use case" that many may find helpful - the "ABC Enterprise Use Case". This is a set of samples that will help to illustrate how xCBL is meant to work. And, we have a great announcement! Mappings, mappings and more mappings. We have completed the first batch of base mappings for xCBL 3.0 to ANSI X12 messages. Check it out, and we would love feedback on how useful this is. Email us at: xcbl@commerceone.com .
These are a set of sample documents placed within a fictitious business scenario, providing sample documents (rendered as HTML for reading in a browser) and brief descriptions of the context in which they are being sent. (A more extensive explanation of the ABC scenario, the actors involved and other information can be found in the associated ABC Use Case Scenario document .) The ABC scenario is set up to show a complete cycle of xCBL 3.0 messages related to the ordering and invoicing of goods. The cycle starts with availability and price check messages followed by various messages for material ordering, modification to the order and order status checking, and is completed with the advanced shipment notice and invoice. ABC Enterprise Company is purchasing parts from Dunn Manufacturing (all names are, of course, bogus!), used in the manufacturing of their own product, which is sold on the B2C market. ABC Enterprises is a buyer using a desktop buying application integrated into their back office, and Dunn Manufacturing is a supplier that uses an application hosted at the trading community portal. This set of documents are all taken from xCBL 3.0. By showing the full flow of documents within the scenario, it should be possible to see more clearly how the data in business documents is reused across the entire business process, helping to show why xCBL models data in certain ways, and clarifying the use of many elements within the documents.
The forward and reverse Standard Mappings of the following messages between xCBL 3.0 and ANSI X12 are now available for download at www.xcbl.org .
A Standard Mapping User Guide is available from viewing and download from the site along with other information and tools that support the use of the mappings. Please read the user guide prior to use/download of the mappings.
When: May 7-11 Where: Vienna, Austria For more info: The ebXML Website In this premier event, the entire XML EDI industry will come together for a week long conference to finalize and present the developments in ebXML. Participate in a wide range of project teams for thorough sessions filled with practical case studies and strategic insights.
When: May 21 - 15, 2001 Where: Berlin, Germany For more info: GCA's Website
When: June 19 - 20, 2001 Where: London Also: June 18 - 19, 2001 in Stockholm For more info: XML for Financial Services The focus will be practical, looking at banking and insurance. The conferences will feature 20+ case studies and contributions from companies who are leading XML implementation and already seeing the results, analyzing the practicalities of implementation. This expert panel of speakers will run through the challenges and advantages of implementation. The speakers will not sell XML as a technology, but give a balanced view of the advantages and disadvantages of its use. Speaking at the conference are companies leading the XML revolution, including OASIS sponsors, Reuters and SoftQuad, and OASIS technical operations director, Karl Best. OASIS members receive a 10% reduction on the advertised price. For information on joining OASIS, go to http://www.oasis-open.org/join/index.html .
When: August 12 - 17, 2001 Where: Montreal, Quebec, Canada For more info: GCA's Website
When: October 1-4 Where: San Francisco, CA For more info: http://www.elinkconference.com/ Prepare to be enlightened by industry visionaries who can help you develop your company's e-business strategy. Participate in hands-on breakout sessions that address your concerns and issues. View a wide array of breakthrough products and solutions from top companies at the Global showcase.
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. Its 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 website. At the moment the Documentation available includes the Document Guide and an HTML Structure Reference - these are also available in downloadable form.) This documentation goes into the workings of CBL 2.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.
Announcing xCBL 3.0 release 2, It corrects a few minor problems found in the December release and adds four new documents: FXRateRequest, FXRateResponse, PaymentStatusRequest and PaymentStatusResponse. xCBL 3.0 is provided in SOX Schema format, XDR Schema format, and XML DTD format to support all types of applications. All of versions of xCBL are available on the website. There is a separate page set up for those using CBL 2.0 and you can download the documentation, schemas, and samples from this page. The xCBL 3.0 download page also provides documentation, samples and schema. The documentation for xCBL 3.0 has changed since CBL 2.0. There is no longer a huge PDF file to download. We now offer an interactive on-line reference guide in HTML. You can use it on-line or download it to your own PC (recommended - this thing is very, very large!)
For Whitepapers on XML, this is a great website. Papers by Charles Goldfarb, Eve Maler, Chet Ensign and others.
The Global Trading Web is the world's largest online trading community. Go to GTW .
ebXML has made a lot of progress since our last newsletter. There are documents out for review and technical documents going over the parts of the project that are almost complete. There are several specifications out for public review. You can find them at http://www.ebxml.org/specdrafts/specs_for_review.htm
That is the tag line for this website. XML.com is full of resouces and information. The publish articles about things going on within the XML community. This site is owned by O'Reilly, you remember them? They are the guys that publish all those great technical books. Check it out!
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: Lisa Seaburg, Stuart Bee and Chris Probert Contributors: Brian Hayes, Arofan Gregory, Lisa Seaburg, Bob Glushko, Sue Probert, and Jack Gager | |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||