|
![[]](/images/x-join.gif){kind=small} |
|
 |
 |
xCBL User's Group NewsletterTechnical 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.March 2000 - Number 2
ContentsFuture Directions for xCBL [^]Just to give you a hint about upcoming additions to xCBL... In the next major release, due out Summer 2000, several new document types will be added to xCBL. These will include:
We will also be re-organizing the component library to leverage XML Namespaces to enhance the modularization of the component library around functional areas. Even further out, we are looking at creating international document types, which will rely heavily on core modules with regional extensions for specific international trading needs. In other areas, we will soon (a month?) be launching xCBL.org - today nothing more than a pointer to our corporate web site - as a full site in its own right. Currently, we are planning to have online news threads, downloadable freeware (for translation between common data formats, other developer utilities), and "customized" areas for paticular corporate users who have extensions or documentation that they are interested in posting. Additionally, we will have all of the documentation, samples, and downloads available today. Technical Tip [^]Identifying Organizations in xCBL [^]There have been several questons about this point recently, and although it is quite simple, it seemed like a little explanation might be useful... In xCBL, several elements use AgencyCode as the value of an attribute to identify a particular organization. The most common of these are the Agency element, the PartNum element, and the Party element, along with its many sub-classes (BuyerParty, SupplierParty, ShipToParty, BillToParty, etc.). We will use an Agency element to give a simple example: <Agency AgencyID="ISO" /> The value of the AgencyID attribute is an AgencyCode. You cannot simply put in a text string here, or you will end up with an invalid document. The declared values in the AgencyCode enumeration are: Other Obviously, this list of agencies providing identification will not be enough for everyone. There are three possibilities here:
Use of a Correlation ID with xCBL [^]Editor's Note: The following article is not directly related to the use of xCBL, but it may help eCommerce developers better understand how to enable complex business processes that involve more than the sending of a simple document. This article is written from the perspective of Commerce One's "Global Trading Web," which is an extreme case of complex business processes, as it addresses the inter-related transactions within the international supply chain. The point of the article is more general than that however - today, in systems using Multipart MIME messages, we have created a hook on which we can hang processes involving more than one business document. A similar process may be useful for other eCommerce systems. Trading partners and services in the Global Trading Web (GTW) communicate by sending messages containing business documents such as purchase orders and associated attachments. The structure of a GTW message is a Multipart MIME envelope with headers as specified in RFCs 822 and 1123. The "Envelope" contains a header, the main document (an xCBL document), and optional attachments. Often a group of messages are related from a business process perspective. For example, a PriceCheckRequest document instance sent by a buyer will have a corresonding PriceCheckResponse sent by the supplier. In a more complex example, a PurchaseOrder instance is related to a PurchaseOrderResponse, OrderStatusRequest, and, subsequently, the OrderStatusResponse. It would be nice to be able to associate these related documents. While some subset of the data contained in the documents could be used, the data subset is not always guaranteed to be unique. For example, it is possible that two identical PriceCheckRequest documents could originate concurrently from the same buyer-trading partner. The Envelope's Correlation-Id provides the mechanism for associating related documents. A Correlation-Id is a string representation of a Universal Unique Identifier (UUID). Specifically, the UUID must be a DCE UUID. The idenifier is comprised of an IP address, time stamp, and the processor clock value. The string representation is exactly 36 characters long. For example, 2fac1234-31f8-11b4-a222-08002b34c003. The 9th, 14th, 19th, and 24th characters are always a dash ("-"). The other characters are hexidecimal digits. For futher information on DCE UUIDs, see http://www.opengroup.org/onlinepubs/9629399/apdxa.htm . Note that this restriction on the format will change in the future. (A.D. 3400, to be precise - the Y3.4K bug!) The basic usage of the Correlation-Id is as follows. The application for trading partner A creates an xCBL document and puts it into an Envelope "A". The application sets the Envelope A's Correlation-Id to a GUID and saves the GUID (associating it with document's representation in the database). The Envelope is sent to trading partner B. Trading partner B's application creates a response document and puts it into Envelope "B." It sets Envelope B's Correlation-Id to the Envelope's A's Correlation-Id. Envelope B is then sent to trading partner A. By using Envelope B's Correlation-Id, trading partner A's application can easily associate the response document to the document sent in Envelope A. In a more concrete example, a buyer-side application sends purchase order to a supplier-side application. The buyer-side application creates an instance of the xCBL PurchaseOrder document populated with purchase order data obtained from the database. The PurchaseOrder is put in an Envelope. The buyer-side application calls an API to generate the GUID and sets the the Envelope's Correlation-Id to the GUID. The buyer-side application saves to the database the GUID in association with the purchase order. The Envelope is sent to the the supplier-trading partner. The supplier-side application saves the received purchase order and the Envelope's Correlation-Id. After the supplier accepts or rejects the purchase order, the supplier-side application creates an xCBL PurchaseOrderResponse document, puts it into an Envelope, and sets the Envelope's Correlation-Id to the saved Correlation-Id associated with the corresponding PurchaseOrder. The Envelope is then sent to the buyer-trading partner. The buyer-side application receives the Envelope and quickly associates - by using the Correlation-Id - the Envelope's PurchaseOrderResponse document with the corresponding purchase order. OBI: Open Buying on the Internet [^]Commerce One has been involved in the Open Buying on the Interent (OBI) effort almost from its beginning because we are fundamentally committed to the development and implementation of open and interoperable standards for electronic commerce. OBI is designed for buying low-dollar, high-transaction (MRO, indirect, non-production) goods over the Internet. It is documented on the web site http://www.openbuy.org/ . Its focus is on a proposed procurement process that involves shopping a vendor's web site. Instead of the shopping cart going to the vendor's systems as an order it goes back to a procurement application like BuySite to go through workflow and approvals. OBI currently uses an EDI syntax for representing data such as shopping cart contents and orders with an XML "wrapper." Commerce One is data compliant with the OBI specifications (xCBL documents are designed through a process that carefully takes OBI into consideration) and partially transport compliant. We support part of the OBI spec in that we will handle a PO in OBI/EDI ANSI X12 syntax using the OBI transport specifications. This means that we can process transactions with any vendor that already has OBI/EDI capabilities. Furthermore, since OBI doesn't support order status checks, price checks, or availability checks, if these are important to the vendor then OBI isn't sufficient, so Commerce One's functionality in this area can be viewed as likely extensions to OBI. However, because of the fundamental decision Commerce One has made to make XML the foundation of our end-to-end solution, we have chosen not to strive for 100% "technical compliance" (as defined in the compliance section 9 of the OBI spec). Our XML solution enables us to support the information exchanges defined by OBI with trading partners who do not have EDI capability. xCBL includes compatibility with OBI, but also supports functionality that OBI does not currently address. Commerce One has actively promoted XML in OBI to perform the same functions while taking advantage of XML's ubiquity, its component architecture for messages, and the computational efficiencies over EDI processing because any XML parser can do the work of numerous ad hoc EDI translators. The XML OBI specifications will supplement rather than replace the current EDI-based OBI specifications and we expect to continue to support both. Commerce One has committed a senior engineering director, Dirk Dougherty, to help drive the "XMLification" of OBI by serving as the chairman of the committee working on this activity. When questioned about the work, he said: "This project is part of the ongoing OBI activity to make e-commerce easier for buyers and suppliers. OBI intends to complete the XML project as early as possible in 2000. Future activitywill address additional types of transactions as well as emerging standards such as W3C XML Schemas and UN/OASIS ebXML." News About W3C Schema [^]The master format for xCBL's models is SOX -- the Schema for Object-Oriented XML -- which was developed by Veo Systems (acquired by Commerce One in January, 1999). SOX was developed to overcome the limitations of XML DTDs, which typically model the content of information elements just as text strings, with some weak numeric typing in certain structures. Electronic commerce applications need to be able to specify stronger semantic constraints to handle some strings as prices, part numbers, and other data types, and to be able to specify the inheritance relationships between standard documents and customized versions. SOX, now in version 2.0, can be retrieved from the W3C as a Note, but XSDL, the proposed W3C standard schema language, will probably replace SOX, Microsoft's XDR, and other XML schema languages in the future. (For those who are interested in learning more about current XML schema languages, you may want to read the white papers and other information at Extensibility's web site. ) In just a month, if all goes according to plan, the World Wide Web Consortium will deliver XSDL, the XML Schema Definition Language, as a Candidate Recommendation. XSDL represents the biggest official change to markup since the DTD - its eventual goal being to replace the archaic DTD with a modern data definition language. Commerce One has been involved with this effort since its inception in August of 1998, so you will see many familiar SOX features in XSDL. There are also a number of features we intentionally left out of SOX version 2.0 (some of them because we expected them to appear in XSDL). In the following we will briefly survey the features of XSDL and chart its likely future course. As expected, XSDL has mechanisms for describing the familiar XML constructs, such as elements and attributes. And, like SOX, it goes beyond DTDs in creating a type system for describing the contents of elements and data. The SOX datatype mechanism is essentially replicated in XSDL as simpleType. Simple types describe the string content that can appear in documents - either as element content or as attributes. There is a set of built-in types and a mechanism to create new simple types from existing ones. The built-in set is about the same as in SOX (boolean, number, date, string, NMTOKEN, etc.) and the derivation mechanism (called "refinement" throughout XSDL) is about the same as well. SOX users will not be surprised here. SOX's elementType, however, is divided into two parts:
However, XSDL, unlike SOX, has truly locally-scoped element declarations. The same element name can appear inside different complex types and refer to entirely different types. SOX's extension mechanism has likewise been divided in two parts:
SOX version 2.0 dropped named model and attribute groups. These return in XSDL. Model and attribute groups provide mechanisms for creating a content model group or set of attributes and reusing them throughout your schema. XSDL also has composition mechanisms similar to SOX. As in SOX, a schema may import another schema and refer to its names (this is called import in XSDL, but namespace in SOX). Likewise, an XSDL schema may be divided in several parts that reference each other (called include rather than join ). The semantics of both import and include are essentially the same as for namespace and join . This represents the major pieces of XSDL - the spec is way too big to cover in such a short space. Many of SOX's innovations are present. The Schema Working Group hopes to publish a "candidate recommendation" in April. This CR represents a request from the Working Group (and the W3C) for people to start implementing and using the specification. This should generate a fair amount of feedback which will be used to further refine the language. If all goes well, a revised version will become a Proposed Recommendation by the end of the summer, and XSDL will be come a full W3C Recommendation (the closest thing the W3C has to a Standard) in the fall. ebXML: Harmonization for E-Commerce [^]There has been a lot of discussion recently about ebXML, and what implications it has for technologists. This brief summary is aimed at keeping you updated on what is going on inside this group, and what impact it will have on business libraries such as xCBL. What is ebXML? [^]The EDI community recognizes that "XML is coming" and that it promises significant benefits in terms of better, easier and wider connectivity, particularly to the small- to medium-size enterprise. Right now, though, EDI documents are at the opposite end of the spectrum from XML in terms of flexibility and understandability. You can't just do a "direct" translation from EDI to XML - it would be as bad as doing a "word-for-word" translation from German into English (or vice versa), because the grammar is different. You won't be able to easily understand the result. Solving this problem is what ebXML is trying to do. Essentially it is a jointly sponsored effort by OASIS, a non-profit XML vendor consortium, and UN/CEFACT, who "own" the EDIFACT standard. EDIFACT is the international version of the EDI standard; X12 is similar, but is US developed and owned. What they hope to achieve is a combination of: the vast knowledge and expertise of the EDI community about what data needs to be exchanged between business to support e-commerce with the XML expertise of OASIS members in developing "good" XML documents to produce a solution that will provide real business benefit. Support for ebXML is wide: the membership list provides an indication of the wide support that it already has. You can also find out more about the what the working groups are doing by going to the ebXML web site . The whole ebXML initiative is being developed in a completely open way. The membership includes many people from the EDI standards world (both UN/EDIFACT and X12), as well as people from the XML community. Commerce One (and the group responsible for maintaining xCBL particularly) is heavily represented at ebXML, in several of the working groups. What Areas is ebXML Focused On? [^]ebXML is divided into a series of committees:
Each group is responsible for its own set of deliverables and scheduling its meetings. These deliverables and schedules are also on the ebXML web site. What are the Implications for xCBL? [^]xCBL fits into the "core components" category, and a presentation of xCBL was made to the ebXML Core Components group at their last meeting in Orlando, Florida. Ultimately, xCBL will become "ebXML compliant", meaning that a 100% safe round-trip transformation will be possible between xCBL and any ebXML-compliant set of business document data, whether in an XML format or in an EDI-based syntax. Core Components [^]Creating definitions of these key XML documents is the responsibility of the "Core Components" working group within ebXML. What they are trying to do is develop a set of re-usable XML definitions or components, (such as for Name and Address, Line Item, etc.) that can be re-used to create the "business documents" such as Purchase Orders, Invoices, Shipping Notices that need to be exchanged between the business and individuals involved in e-commerce. The idea behind ebXML Core Components is to model the business data in a syntax-neutral fashion, such that the semantics of the business documents are captured for implementation in whatever syntax is being used. Further, the group is developing a set of "business context" classifications, to enable more intelligent extension and reuse of the core library of components. The Core Components group will produce a sample implementation of the semantics in XML, and will also produce a methodology for re-use of the core components, and a methodology for implementing the syntax-neutral components in both XML and EDI syntaxes. Business Process [^]Developing the business documents is only one part of the problem that needs to be solved. You also need to define how those documents can be used to support business processes. Put more simply, if, for example, you send a Purchase Order to someone, you need to know, in advance, what you expect to get back. For example, if you expect an Invoice, but, instead, you get a Purchase Order Response, then your business process won't be able to cope. To solve this problem the "Business Process" group within ebXML is developing definitions of the business processes required for e-commerce, and how documents need to be exchanged to make those processes work. The goal of this group is to define a set of reusable "sub-processes," and to define a UML-based methodology for describing business processes that is both human-readable and machine-processable. There is obviously tight coordination between the business process group and the core components group, as there is a strong correlation between re-usable data components and the business sub-processes that they support. The goal of this group is to support the reuse of business process models across industry verticals, so for example, the abstractions in a RosettaNet PIP could be moved to the automotive industry. Transport [^]The next problem that ebXML is solving is called "Transport, Routing and Packaging". It's one thing to be able to create a document and send it to someone, but, suppose it "got lost" on the way or, the response you were sending back didn't get through. Another problem is knowing/validating who actually sent the document. If the document is requesting you to do an ACH payment into someone's account, you need to know that the request is authentic. So in short, the Transport, Routing and Packaging group is developing approaches that will provide reliable, robust secure exchange of XML or other electronic documents between the parties involved in e-commerce. Registry and Repository [^]The ebXML Registry & Repository Project Team has completed work on business requirements for a registry and repository ofobjects needed by the ebXML project as a whole, particularlyprocess models, and is reviewing its set of use cases for aregistry and repository. It is hoped that it will be possible togenerate interfaces programmatically, and that the ebXML-specific registry and repository can build on the OASIS Registryand Repository Technical Specification. In next month's xCBL Newsletter we will start looking at the work being done by these working groups in more detail. Upcoming Events [^]eLink 2000 - E-Commerce Solutions for Global Trading [^]When: April 5 - 7, 2000 [^]Where : Walt Disney World Dolphin Hotel, in Orlando, Florida It's the industry event of the year - the place to know about business-to-business e-Commerce. For information: http://www.elinkconference.com/orlando/onsite.htm XML and Electronic Commerce: Commerce One's European XML Event [^]When: May 5, 2000 [^]What : A one-day seminar introducing the XML vision and technology of Commerce One and some of its European technology, systems integration, and standards partners, kicked off by a "big name" keynote speaker. Details to be posted on Commerce One's web site and xCBL.org by early April. ebXML Meeting in Brussels [^]When: May 8 - 12, 2000 [^]Where : Held in Brussels, Belgium and hosted by: CEN/ISSS. For more information go to: ebXML.org XML Europe 2000 [^]When: June 12 - 16, 2000 [^]Where : Held at the Palais des Congres de Paris in Paris, France. For more information: http://www.gca.org/attend/2000_conferences/europe_2000/default.htm Commerce One employees will be presenting on issues concerning the use of xCBL, design issues in general, and other XML-related aspects of B2B e-commerce. Watch the web site for a posting of scheduled presentations and classes. From the web site: XML Europe 2000 explores the many different ways XML, SGML, and their families of associated standards are being used now and will be used in the future. As the GCA's annual comprehensive event on applications, trends, and technologies supporting these standards, delegates will find information for managers, users, and technical experts. Full- and half-day tutorials will help newcomers to the topic as well as provide opportunities for experts to explore favorite subjects in more depth. The four concurrent tracks running throughout the 4 days and the concurrent tutorials on Monday preceding the conference reflect and examine the many faces of XML and related standards. Experts in a range of technical and industry areas discuss not only the more traditional uses of these standards (e.g., documents and data), but also some of the newer applications like e-commerce, or less obvious ones, such as using XML to describe software processes. Where to Go for Help [^]General information about xCBL and related XML technology The SOX Tutorial (PDF) XDK (includes CXP, the Sox Parser, and an integrated XSL transformation engine) Documentation (includes the Document Guide and an HTML Structure Reference - these are also available in downloadable form.) XML Publications and Resources [^]Publications written by individuals here at Commerce One are available at:http://www.commerceone.com/xml/publications/index.html There is now a training course available for those interested in learning about how xCBL, SOX, and XML in general are used inside Commerce One's products. For those interested in learning about XML in general, especially as it is used with schema, one company comes highly recommended: Isogen . Important Links [^]Commerce One's page of outside endorsements of xCBL . BizTalk (you must register with the BizTalk repository before getting access) Robin Cover's OASIS SGML/XML Web Page . Great place to find all kinds of information. 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 And more news from ebXML go to their news link Job Opportunities [^]Commerce One is looking for individuals to fill the following positions working with xCBL, XML Messaging, and similar open-standards-based technology: XML Experts: Experience working with SGML/XML for 3+ years, a solid knowledge of standard XML tools and related standards, and experience writing editing DTDs/XML Schemas. Knowledge of EDI a plus. Experience in standards activities desirable. XML Developers: Experience developing SGML/XML applications using standard tools/programming languages: XSL, Python, Java, Perl, etc. Knowledge of distributed computing and/or relational/object database technology a plus. XML Technology Marketers: Experience with product management and standards promotion; solid knowledge of the capabilities of applied XML technology. Business Analysts: Experience with business analysis for enterprise information systems; knowledge of internet technology and the capabilities of applied XML technology a plus. Document Engineering Program Manager: Combination of strong technology and software development skills, along with excellent process and interpersonal skills for coordination of projects across product lines. We are also interested in hiring anyone 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 . We will consider having people in some positions working remotely. Subscription [^]Subscription to this newsletter is through Commerce One. To subscribe or unsubscribe, please send an email to: xcbl@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". About the xCBL User's Group Newsletter [^]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, Terry Allen Designer: Lisa Seaburg Contributors: David Burdett, Arofan Gregory, Lisa Seaburg, Matthew Fuchs, Dirk Dougherty, Terry Allen, Bob Glushko, Brian Hayes
|
|
|
|
|
|
|||