|
![[]](/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.April 2000- Number 3
ContentsEditor's Note [^]xCBL is an XML business language that is meant to be used by anyone needing a full-featured language that has sufficient complexity and detail to be used for the kinds of applications that older EDI standards are often used for today. (In upcoming newsletters, we will be releasing mappings between the xCBL business documents and their standard EDI equivalents.) It is created to be (and supported as) a non-proprietary standard, for use by anyone who needs it. We recognize that xCBL is most often used by those who are deploying Commerce One's technology, and you will find that many of the articles in the newsletter focus on Commerce One's products. It is in the interests of every eCommerce company to promote standards, whether they are related to XML business documents, messaging and transport, choreography and workflow, etc. We frequently interact with users who do not use Commerce One's products, and want to make sure that this newsletter offers value to those who are using xCBL with any applications whatsoever. In the long run, vendors who support standards will find themselves more successful as a result of their being more interoperable. xCBL is the XML document set that Commerce One uses, but we are not its only users - this newsletter is created to support all of xCBL's users, and not merely those who use Commerce One products. The Value of Business Semantics: A Comparison of the "Business-to-Business" and "Application-to-Application" Approaches to Interoperability [^]In using xCBL, you will recognize that the elements in the library refer to the content they contain, primarily as a way of identifying the semantic relationships of the business information. In simple terms, xCBL elements attempt to identify not what the processing application that produced the information stored it as, but what the information is in a business sense. This approach toward business data is not the invention of xCBL - it is inherited from the EDI documents that are the basis of xCBL. We like to refer to this approach to business document information as "business-to-business," because it focuses on the human-oriented, business reasons for the information exchange. There is another approach to describing business information, which uses an application focus ("application-to-application"). In this approach, business information is described in terms of how the business applications that interact with it store it and process it. The idea is that ERP vendors will agree on a standard set of messages to exchange information about the core processes of their systems. This approach is very popular among vendors who need a way to adapt their legacy installations to the new and more heterogeneous situations. xCBL is very much designed around the "business-to-business" approach, and we feel that this decision is well-justified. One of the major benefits of a loosely-coupled document-based integration between trading partners is that they do not have to worry about tight integrations with the systems of their trading partners. As Internet technology allows relationships between trading partners to become more dynamic, the time required to tightly integrate systems vanishes. The number of trading partners for any given enterprise will increase dramatically, making the old-model point-to-point integrations difficult (if not impossible) to maintain. One of the most valuable aspects of this phenomenon will be visibility along the whole of the supply chain, including not just the top-tier suppliers, but many small- and medium-size enterprises as well. We do not believe that application-to-application business documents will scale to meet this demand. In the first place, smaller trading partners may not be able to afford (or even need to implement) the same kinds of ERP systems that large enterprises use. An application-to-application approach means that if you want to play in the eCommerce game, you need to have an ERP system that will enable you to do it. We feel that this effectively chops off the bottom of the supply chain. Further, the whole idea of standards is to allow business information to be processed without tight control by applications vendors. Enterprises should be free to choose those applications that best fit their business needs, and should be able to rely on standard information encodings to protect them from the proprietary tendencies of software vendors. Business documents based on an application-to-application approach put their users at the mercy of the vendor consortium that produced the application-based standards. Over the long term, your business decisions should not be controlled so closely by vendors, if only because you have no control over what ERP systems your trading partners will be using. Further, semantic descriptions of business data are easier for humans to understand, making the creation and maintenance of a wide variety of applications easier for developers. Business data is often extremely complex, even without being tied too tightly to the processing behaviors of ERP systems. If a sophisticated knowledge of ERP applications is required to understand the messages used in e-commerce, the number of people qualified to develop these systems shrinks dramatically. Application-to-application standards are very useful, in their own sphere: when you have control over the processing systems, as occurs within the many sites of a global company, then they can actually ease deployment and maintenance. In this scenario, the enterprise has already made a significant investment in terms of people who can understand the standard ERP implementation. The use of applications within the enterprise - no matter how widely distributed across the globe - can be known and controlled. Under these circumstances, application-to-application standards make a tremendous amount of sense. Using a business-to-business, semantic approach to messages involves a level of indirection that can require more implementation effort up-front: you cannot merely buy the appropriate ERP system and know that you can easily communicate with anyone else using a similar system. This extra effort is worth it, however, because it allows you to trade more easily with a larger number of trading partners, and to maintain your systems over time, as ERP technology matures and changes. Ultimately, using business semantics instead of application semantics introduces a layer of indirection that may be slightly more expensive in the short term, but that more than repays the implementor in terms of freedom to use whatever software best meets the user's needs, and in minimizing maintenance and development costs over time. xCBL, like most of the XML e-commerce standards today (RosettaNet, OBI, ebXML), and like the current EDI standards (X12, EDIFACT), has decided to embrace a business-to-business approach in describing business data. We feel that this is, ultimately, in everyone's best interest. ebXML: Transport Working Group [^]Last month's article provided an overview of ebXML and what it is trying to achieve. This month we look at the work of the Transport sub-group in more detail providing:
Commerce One's David Burdett is the editor of the working group - Commerce One takes standards activities seriously - we know that our business partners and customers prefer to use open standards whenever possible. Commerce One is also committed to implementing ebXML standards as they develop and become more stable. Messaging Problems You Need to Solve [^]Before looking at the Transport Working Group in more detail, let's look at the problem that the group is trying to solve. At its most simple level, transport or messaging is about ensuring that the outer electronic envelope is understood by both the sender and the receiver of a message. To take an analogy from the real world, consider the diagram below that illustrates different ways of sending paper or other physical documents. 
Figure 1. The most popular way of sending mail is to use the national government-operated postal service such as the United States Postal Service (USPS). However if you want to send a letter quickly and reliably from one place to another, then you make use of companies such as FedEx or UPS who provide reliable courier services. The USPS, FedEX and UPS, though, have their own forms that must be used to address their packages, be it the particular style in which you write the destination address on an ordinary envelope or the multi-part pre-printed forms used by FedEx and UPS. Unfortunately, though, you have to use the correct form or the postal service that is transporting your package won't be able to handle it. The same applies in the electronic world as illustrated by the diagram below. Figure 2.  Just as in the real world, the document you want to send, for example a Purchase Order defined in xCBL, must be placed inside an electronic envelope before sending it on its way. Also, just as in the real world, the structure of the electronic envelope needs to be understood at each end - otherwise it won't work. There is also a need for reliable document transport, but unfortunately the web is not sufficiently reliable. This means that using ordinary email or HTTP is not good enough. So before easy and reliable "Plug and Play" eCommerce can be realized two problems need to be solved:
Commerce One's MarketSite has solved this problem by implementing a reliable message delivery mechanism inside Commerce One's XML Commerce Connector (XCC). This means that, when you need to use it, you can be sure that your documents will get through, and, if delivery is just not possible - if the destination server is down, for example - then you will be informed of the failed delivery. Commerce One developed its own messaging approach since no standard alternative existed at the time. We realize though that our business partners and customers want to use open standards to support this - hence our active involvement in ebXML. What ebXML Transport Is Doing [^]So how is the ebXML Transport Working group tackling these problems? To summarize:
There are many protocols being used for messaging of one type or another already. To address this the working group first analyzed many existing transport protocols in the eCommerce area such as: cXML, EDI, EDIINT, IBM's MQ Series, ICE, IOTP, Microsoft BizTalk, OAGIS, RosettaNet, X12. Then it developed its own set of headers and will shortly be mapping these existing standards to ebXML to identify the gaps. Any gaps that are found will then be fixed. The basic idea is that you should be able to "map" from one set of message headers to another so that you can easily create "bridging software" that allows you to convert from one message format to another. Other planned features for ebXML Transport include:
It is envisaged that software vendors will be able to develop solutions that sit between the true transport layer (e.g. for HTTP or SMTP) and the business application (e.g. a Purchase Order handling application) that remove the need for the business application to provide support for the features highlighted above. Current Status [^]At the time of writing the group is working on providing a simple demonstration that shows how the message headers can work over both HTTP and SMTP. It is hoped that this will be ready for the next ebXML meeting in Brussels in May 2000. Future newsletters, will provide an update on how it went. Next Month [^]Next month we will look at the work of the ebXML Core Components group in more detail. Western Illinois University Legal Study [^]Business Forms in the XML Common Business Library [^]Dr. Laurence Leff, a professor of computer science at Western Illinois University, is starting a study involving the integration of two separate developments in computer information applications: electronic commerce and the automated submission of legal documents to courts. Specifically, he is looking at integration of the Business Forms in Commerce One's XML Common Business Library with Litigation and Arbitration procedures. Here are some excerpts from his proposal: The Electronic Court Filing Project is developing XML standards for Court Documents, Contracts and other legal documents. The Legal XML Group has developed a proposed standard for Court Filings such as the initial complaint that would start the lawsuit. Analyze the model form contracts developed by the Legal XML group for compatibility with the Common Business components. The legal XML group has already produced a proposed electronic court filing standard in association with the National Association for Court Management and the Conference of State Court Administrators. Their "Horizontal" workgroup is developing DTD's for items common to many legal documents such as names and addresses. I would identify anything that is not compatible and make the appropriate proposals to the Legal XML Group and/or the XML Common Business Library's users group. I would also ensure that all information needed for the XML court filing wrapper is present in the XML Common Business Library XML definitions. This effort might include new namespaces. If you would like to contact Dr. Leff, his contact information is: Laurence L. Leff, Ph.D., Associate Professor of Computer Science, Western Illinois University, Stipes Hall 447, 1 University Circle, Macomb, IL 61455-1390, Telephone: 309-298-1452. [Editors Note: If you have an interesting application for xCBL, tell us about how you are using it, and we will publish an article like the above.] Call for xCBL-Supporting Tools [^]We want to publish a list of tools vendors who provide native xCBL support, as well as run feature articles on specific tools. If you work for a company that is implementing or has implemented such support, please contact us with the following information:
Please get this information to us as soon as possible: we will be printing this list in the May newsletter if possible. Write xcbl@commerceone.com with the words "TOOLS LIST" in the subject field. HotFS 3.1, makes it even easier to speak XML with MarketSite [^]HotFS (Hot File System) is a new MarketSite integration component that can be used by both buyers and suppliers. The HotFS component is intended to be a lightweight, easy to use and highly generic solution for integration with Trading Partner systems where integration using XCC directly is not suitable. HotFS is designed to allow integration by simple generation and parsing of XML files. As such, HotFS can be used to integrate with a MarketSite marketplace any system that can generate and read XML files. HotFS can be used for all aspects of MarketSite communication: sending documents, receiving replies, receiving documents and sending replies. In integration using XCC, or other common connector technologies, the integration will be done through programming APIs, such as the XCC java interfaces. With HotFS, integration is done by generating and reading XML documents that represent the business documents that are exchanged. Thus, no programming to connector APIs is required. All information communication between HotFS and the integrated system is expressed in XML. This includes transmission specifics, configurations and errors as well as the business documents themselves. This way the trading partner system can communicate where and how to send documents of any type, without knowing any of the specifics of communicating with MarketSite. The trading partner system also receives all transmission information from HotFS in the same structured XML format that can be easily processed or communicated to a user. HotFS is highly flexible and will function for any XCC communication purpose. The integrated system can send any type of XML document without changing HotFS configurations. The integrated system can subscribe to any type of documents merely by specifying the desired types in the HotFS configurations. In contrast, a direct integration requires an implementation change if new types of documents are to be sent or received. It should be noted, however, that simplicity and flexibility commonly is traded for other characteristics. As an example, HotFS has not been designed to be an optimal solution for systems with high volumes of transactions. HotFS' sole purpose is to enable communication between the trading partner system and MarketSite through a simple XML interface. It is a fast and simple way to get trading partners integrated and transacting. HotFS is particularly useful when development of connector specific code is difficult or undesirable. HotFS provides a very easy to use solution for XML document exchange with MarketSite marketplaces. Technical Tips [^]XML Document Interoperability Between SOX-Based Systems, XDR-Based Systems, and DTD-Based Systems [^]One of the advantages of using XML to encode e-commerce messages is not having to care about how trading partner's systems are implemented: the dependencies are focused on the document exchange. One aspect of potential difficulty, however, is the multiplicity of document validation schemes within the XML world: I can validate against DTDs, against SOX schemas, or against XDR schemas, and soon XSDL schemas will be joining the mix (and this list only contains the major schema languages - certainly not all of them!) It would be great if we could simply use any of these validation technologies on any XML document, but the reality is that XML standards have not yet developed to this point. While the differences between the actual XML documents exchanged are minor, they are very real, and will need to be taken into account by those building processing systems to handle xCBL documents. The Problem [^]When processing documents with a traditional "DTD" parser, we expect to see a doctype declaration at the top of the file: <!DOCTYPE PurchaseOrder SYSTEM "CBL.dtd"> Here, we see the string "<!DOCTYPE" followed by the name of the root element, with a keyword (either SYSTEM or PUBLIC), followed by a value that points to the location of the DTD. (The "PUBLIC" keyword uses a unique identifier to trigger a catalog lookup; the "SYSTEM" keyword points to the DTD with a locally resolvable path in the form of a URL.) Here, the doctype declaration points to the CBL DTD, to validate a PurchaseOrder document. In a system that validates with Microsoft's XDR schemas, we will have XML namespaces, used according to the Microsoft convention. The same document would have the following attribute included in its start tag: <PurchaseOrder xmlns="x-schema:cbl.xdr"> Note that the value of the attribute "xmlns" is a URN, which uses a conventional prefix "x-schema:". Without this prefix, the URN points to the schema, but indicates to the Microsoft XML parser that it is not expected to validate the document against the schema. For SOX-validated documents, a "soxtype declaration" is required. This is an XML processing instruction that points to the SOX schema against which the XML document is to be validated by the SOX parser: <?soxtype urn:x-commerceone:document:com:commerceone:CBL:CBL.sox$1.0?> Here, we have a keyword "soxtype" followed by a URN that follows the hierarchical conventions of Commerce One: everything after the "urn:x-commerceone:document:" shows the path from the root of the repository (as configured in the parser) to the location of the xCBL schemas. If you are extremely clever (that is, too clever for your own good), you will note that it would be possible to include all three types of pointers in a single XML document, because each is different. Great! No problemo! Alas, this is not the case. If you pass a document to the SOX parser that contains a doctype declaration and a soxtype declaration, the parser will validate the document against the DTD first. This is typically not just an undesirable behavior, but a fatal one: not only don't you get the desired schema-level validation, but it is not usual for the DTD to exist in a system based on SOX. If the parser can't find the DTD, you get a fatal error. Similar bad things happen when you include an "xmlns" pointer to an XDR schema as well as a soxtype declaration. The parser will find the SOX schemas (if that is what it is expecting) but also understands XML namespaces, and tries to resolve the XDR schema URN, perhaps even successfully. But the SOX parser doesn't understand the XDR schema syntax, so the parser will produce a fatal error. Microsoft's schema parser also understands DTDs and their doctype declaration pointers, and will validate with these in preference to XDR schemas. Just as with the SOX parser, a doctype declaration will generally produce an error, and when it does not, it will result in weaker-than-expected validation. Because "soxtype declarations" are just processing instructions, however, the XDR parser will ignore these. A DTD parser will also ignore a "soxtype declaration", but it will try to resolve the "xmlns" attribute on the root tag if there is one. Typically, this will result in an error, because even if the URN can be resolved, it will not resolve to a DTD, but will resolve to an XDR schema, resulting in a fatal error. The Solution [^]It is easy to avoid these problems, however, with a little foresight:
It is devoutly hoped that the XML community will come up with some way to resolve these problems. This author's preferred technique is the use of processing instructions, as in SOX: this is the time-honored SGML way of making application-specific markup invisible to other kinds of processors, and it doesn't make assumptions about the use of XML namespaces, which have a standard and expected use. Regardless of how this problem is solved, you must be aware of the dangers it presents. Make a few phone calls to your trading partners, and then write the few lines of script that will allow you to avoid trouble. Developer's Note: When testing scripts or other code used to solve these problems, it is very helpful to have three tools available: (1) cxp, the Commerce One SOX parser, available free as part of the XDK (go to the XDK download area of xCBL.org); (2) Internet Explorer version 5.0 or later - this has the Microsoft XDR parser built in; (3) a DTD-validating XML parser. There are many - I use nsgmls, configured to run in XML mode, available from James Clark's web site, free of charge, as part of the "SP" package. Make sure and read the documentation about configuring it for XML, however, as it is also a full-blown SGML parser. How to Support BLOB Objects in SOX Schemas [^]Often, the nature of e-commerce requires non-XML documents to be transported along with the XML business documents. In these cases, it is important to remember that SOX is an XML schema specification and not a messaging protocol. However, there are at least two possible ways to support BLOBs (images, word processing documents, binary data, or other data/file formats) using SOX. One way is to encode the BLOB data, perhaps using BASE64 encoding, and put the data in an appropriate field in the XML document. For example, the SOX snippets for this schema might be: <elementtype name="BLOB"> <model> <string/> </model> <attdef datatype="Encoding"><required/></attdef> </elementtype>
<datatype name="Encoding"> <enumeration datatype="NMTOKEN"> <option>BASE64</option> <option>BINHEX</option> <option>UUENCODE</option> <option>MutuallyDefined</option> </enumeration> </datatype> Another way is to use the SOX specification in conjunction with, say, a multi-part-MIME based message specification. The BLOB data can be expressed as an attachment in the MIME message. The SOX datatype URI is used to create an attribute or element that can be set to the reference to specific attachment(s) in the MIME message. If the data was made available on a server, then the URI attribute/element could be set to the URL of the data. An example of this approach is found in xCBL. A business document would look like this: <Attachment Attachment="[URI goes here]"> <Purpose>[String value]</Purpose> <FileName>[String value]</FileName> <Title>[String value]</Title> <Language>[Language Code, per xCBL datatype]</Language> </Attachment> Note that the Attachment attribute is a required value of datatype URI. The attachment would be included in the multi-part MIME message with the business document that references it. To see the SOX schemas for the xCBL element Attachment go to (http://www.xcbl.org) . Cost Centers in the xCBL PurchaseOrder and Other Documents [^]We have had several requests from people who wish to include cost-center information in their xCBL documents. This kind of use of xCBL demonstrates how the less-obvious pieces of information in business documents can be captured in the xCBL documents, without resorting to extensions (which can be extremely useful, but require more coordination among trading partner implementations in some circumstances). Note, too, that Cost Centers are not generally provided for in EDI business documents, either, so that determining the "usual" way to model them is not simple. In the header elements of xCBL documents, you will generally find the OrderReference element, either used directly, or renamed. In the case of PurchaseOrder, we find OrderReference used directly. An OrderReference element contains an AccountCode (of type Reference), a BuyerRefNum (of type Reference), an optional SupplierRefNum (of type Reference), and an optional ListOfReferenceCoded. It is this last element that is non-obvious in its application, but that gives us a flexible way to include cost-center information in a business document. A ListOfReferenceCoded is a simple list of ReferenceCoded elements. ReferenceCoded is an extension of the Reference element. Reference contains a RefNum element of type string and a RefDate of type datetime. To these, ReferenceCoded adds RefCode and an optional RefCodeOther. RefCode is an enumerated datatype with the following values: Other CustRefNum ContractNum PrevProdCat PriceListNum ProdInqNum Because none of these codes indicates that the CodedReference is a cost center, you need to use the Other value, and then employ the optional RefCodeOther element. The datatype of RefCodeOther is a simple string, so the obvious choice to include would be "CostCenter". Note that the parser will not validate this beyond checking to see that it is a string, so the processing applications will need to validate it. In the business document, the RefNum will hold the reference number of the cost center, and the RefDate will contain the date of the business document's creation. Note that, because ReferenceCoded extends Reference, there will be no "Reference" tags in the business document here: the ReferenceCoded will contain RefNum, RefDate, RefCode, and RefCodeOther as its direct children. As you will no doubt notice, this same technique could easily be used to encode any other type of reference that you needed to make in the business document - simply agree with your trading partners on what the RefCodeOther field will contain, and then select the Other value for RefCode. Questions and Answers: xCBL E-Mail Exchanges [^]What follows are a couple of exchanges taken from e-mail received at xcbl@commerceone.com, along with the responses provided. We felt this might be helpful to some of you. (Note: All names have been changed to incriminate those against whom we have particular grudges...) USER: I downloaded the DTD files for xCBL but cannot get IE5 or Netscape5 to properly read them. I need to speak to someone who understands how DTD and XML files go together. TECH SUPPORT: Use a text editor to open them (NotePad, etc.). DTD's are not generally designed to be read from a browser. Also, you may want to go to http://www.extensibility.com/ and down load a trial version of XML Authority. It is designed to read both DTD files and schema files. USER: A feature of IE5 is the ability to read XML documents and their associated DTD to display them in human-readable format. This is one of the basic tests we use to confirm that an XML document matches its DTD. When I try to open the sample xCBL documents I get an error. I believe the problem is either a naming or directory convention issue on my end and would like to chat with someone who knows the issue. TECH SUPPORT: [We actually called this fellow...] The problem was that he had unzipped the xCBL DTDs that he had downloaded with a version of PKUNZIP that truncated long filenames. This produced a mismatch between the names of the files in the unzipped directory, and the entity references in the "master" DTD file (CBL.dtd) that pulls them all together for the parser. Quite rightly, the IE5 XML parser choked, since it couldn't resolve the entities - the file names in the directory didn't match the ones supplied in the DTDs. Note: If you open up a DTD or XDR sample from the downloaded ZIP on the web site (without first unzipping it), or if you download the HTML pages that present the samples in human-readable form, then they won't parse, because in the first case they can't see the DTD (it's still in the ZIP) and in the second case the document can't parse because it's not actually an XML document, it's just an HTML page for viewing. These are fairly common mistakes among the less-technical folks who look at this stuff, but are at least easy to fix (download the zip files and unzip them, then work from a local directory). Upcoming Events [^]The Power of XML: Today and for the Future [^]When: May 5, 2000, 8:45 AM - 500 PM [^]Where: BT Milton Gate, 1 Moor Lane, London EC2Y 9DX Topics include:
Who should attend? This event is aimed at technical management and engineering personnel, with responsibility for supplier adoption and integration, design of vertical markets in specialized areas, deployment of new portal services and product integrators. By providing a solid technical background, businesses will be positioned to make fully informed decisions on planning, staffing and budgets for deploying Commerce One's XML-based technology. 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) XML Publications and Resources [^]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 is 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: Brian Hayes, David Burdett, Arofan Gregory, Lisa Seaburg, Matthew Fuchs, Dirk Dougherty, Terry Allen, Bob Glushko, Mette Hedin
|
|
|
|
|
|
|||