Downloads
	Release Notes
	License Agreement
	Endorsements

	FAQ
	Links

Send us your comments on cXML.
comments@cxml.org

cXML Release Notes

This document describes the changes between versions of cXML. For complete descriptions of all changes, see the cXML User's Guide.

1.2.021

TaxDetail Element

The TaxDetail element now includes an Extrinsic element so additional tax-related information can be included. TaxDetail also includes a new attribute, exemptDetail. The exemptDetail attribute allows specification of why an item has no tax.

Tax Element

The Tax element now includes an Extrinsic element for additional tax-related information.

StatusUpdateRequest

The StatusUpdateRequest element now includes an Extrinsic element. This can be used for additional information about the status of the document being updated.

1.2.020

SubscriptionStatusUpdateRequest Documents

A new transaction, SubscriptionStatusUpdateRequest, is now included in Catalog Subscriptions.

invoiceOrigin Attribute

The InvoiceDetailRequestHeader element now includes the invoiceOrigin attribute for invoice categorization purposes.

1.2.019

Expense Extrinsics for TimeCards

The TimeCard element now includes expense extrinsics. This allows contractors to include expense information in time cards and submit them to their customers for verification.

Organization Data Requests

Buying organizations can now use the OrganizationDataRequest transaction to receive supplier profile information and updates from the Ariba Supplier Network.

PaymentRemittanceStatusUpdateRequest Extrinsics

The PaymentRemittanceStatusUpdateRequest element now supports extrinsics. The OriginalSupplierAccountNumber, CorrectedSupplierAccountNumber, OriginalSupplierBankAbaNumber, and CorrectedSupplierBankAbaNumber extrinsics allow buyers to validate bank account information entered by suppliers.

1.2.018

Asset Information in Ship Notices

Serial numbers, asset tags, and extrinsics are now allowed within ShipNoticeItem elements. This allows suppliers to provide product serial numbers and asset information to their customers for verification.

Blanket Purchase Orders

The OrderRequest element now supports blanket purchase orders, a type of purchase order that specifies a blanket amount committed to be spent without requiring all the details when the purchase order is created.

Line-Item Credit Memos

The InvoiceDetailRequestHeader element now allows suppliers to send line-item credit memos to provide buyers with detailed information on credits and to comply with EU requirements. This allows suppliers to create a new credit memo type in addition to the header level credit memo.

Level 2 PunchOut Enhancements

The PunchoutDetail element now allows suppliers to provide more catalog details on products: the unit price, lead time, and unit of measure. Procurement applications can use this information to enhance the search experience.

LaborDetail Extrinsics

The LaborDetail element, which describes temporary labor in the SpendDetail element, now supports extrinsics. Buyers might want to send their own extrinsics to the supplier, such as the region in which the work is done.

1.2.017

Multiple Signature Support

Multiple independent digital signatures on a document may be required. cXML 1.2.017 now allows multiple occurrences of the ds:Signature element in a cXML document. This may be useful in some situations, such as cross-border trade that must conform to VAT invoicing rules.

XAdES 1.3.2 Support

cXML 1.2.017 now supports XAdES 1.3.2. XAdES 1.1.1 is no longer supported. Documents conforming to the cXML 1.2.017 DTD that need to use XAdES must use XAdES version 1.3.2.

1.2.016

New Correspondent Element in Headers

cXML documents can identify unknown sending or receiving organizations with a new Correspondent element. This element can appear in the To or From elements in the cXML header. It identifies organizations that are not known to one of the parties involved in the transaction.

New punchoutLevel Attribute

cXML PunchOut index catalog items can use a new punchoutLevel attribute to specify the type of PunchOut available: store, aisle, shelf, or product. Procurement applications can display these items differently to indicate the type of PunchOut available.

1.2.014

Scheduled Payment Document

Scheduled payment (PaymentProposalRequest) documents allow buying organizations to inform their suppliers about planned payments. They list future payment dates and discounts and can be for information only or for triggering payment.

InvoiceIDInfo Added to StatusUpdateRequest

Buying organizations can now use the new InvoiceIDInfo element to identify invoices in StatusUpdateRequest documents. This element identifies invoices by invoiceID and invoiceDate. Previously, buying organizations could identify invoices only by payloadID.

1.2.013

New Data Download Transaction

The data download transaction (DataRequest and DataResponse documents) allow cXML clients to download waiting documents that reside on cXML servers. Clients use the get pending transaction to poll for waiting documents. The server returns a DataAvailableMessage element to indicate that there are waiting documents. Clients then use the data download transaction to download those documents. The server returns waiting documents in a Multipurpose Internet Mail Extensions (MIME) envelope.

PCard Element Added to Payment Remittance Document

The PCard element has been added to the PaymentPartner element within payment remittance documents. Buying organizations can use this element to charge purchasing cards after they approve invoices.

remitTo Role Added to PaymentPartner Contact

remitTo has been added as a possible value for the role attribute in Contact elements within the PaymentPartner element. Buying organizations can use this value to specify suppliers’ remittance addresses in PaymentRemittanceRequest documents.

1.2.012

New Description Element Added to Invoice SpecialHandlingAmount

The invoice SpecialHandlingAmount element has a new Description element. Suppliers can use this element to describe the reason for the special handling charge.

1.2.011

CopyRequest Enhancement

Buyer and supplier organizations should now use attachments to fulfill copy requests. In cXML 1.2.011, the use of the cXML element as a child of CopyRequest is deprecated. Instead, use the cXMLAttachment element to attach another cXML document, whether or not it contains attachments itself.

New PaymentRemittance Transaction

PaymentRemittanceRequest and PaymentRemittanceStatusUpdateRequest documents allow buying organizations to pay suppliers for provided products or services. These documents allow buyers to specify payment schedules, specify discounts, and send payments regardless of where payments are made, and to ensure that payments have been received.

The PaymentRemittance transaction supports payment transaction details for a wide variety of business scenarios, including standard invoices, credit memos, and debit memos.

Procurement applications send PaymentRemittanceRequest documents and suppliers respond with generic response documents. When payment transaction status levels are updated, procurement applications send PaymentRemittanceStatusUpdateRequest documents.

InvoiceDetailPaymentTerm Deprecated

InvoiceDetailPaymentTerm is deprecated in cXML 1.2.011, in favor of PaymentTerm (described below). cXML implementations for payment should use PaymentTerm.

New PaymentTerm Element

Defines the payment term in orders and invoices. This deprecates the InvoiceDetailPaymentTerm previously defined. PaymentTerm defines either the net term (without discount) or the discount term (with discount).

Digital Signature Support

Any cXML Request, Response, or Message can now be signed using W3C XML Digital Signatures. Support for the XAdES (XML Advanced Electronic Signature) standard is also included. A valid cXML signature is an XML signature with certain properties, so additional signature elements now appear in all DTD files.

New SpendDetail Element

The new SpendDetail element enables buyers and suppliers to automate the transaction process for spend in three new categories: travel, fees, and labor. There are three new elements within SpendDetail: TravelDetail, FeeDetail, and LaborDetail, in addition to the Extrinsic element.

TravelDetail Element

TravelDetail contains information about travel line items for air, car rental, hotel, and rail in ItemIn and ItemOut elements. In addition, cXML 1.2.011 supports the use of Extrinsic elements in SpendDetail, to enable buyer-supplier pairs to convey detailed information on spend that is not yet explicitly defined in cXML.

With cXML 1.2.011, users can access a travel booking provider's website and make travel reservations. To meet the particular requirements of the travel industry, TravelDetail supports an OrderRequest of type "delete", which can be sent to a travel booking provider after PunchOut to cancel an existing reservation. This also enables suppliers to cancel a leg of an air trip, for example, while replacing it with a new air leg. New transactions are in cXML.dtd.

FeeDetail Element

The new FeeDetail element of SpendDetail conveys information about one-time or recurring fees that are not explicitly defined elsewhere in cXML. For example, a one-time fee for furniture rental would not fall into any category defined in TravelDetail or LaborDetail, but could be described in FeeDetail.

LaborDetail Element

LaborDetail contains information about an item related to temporary labor.

Extrinsic

The use of Extrinsic details is now supported in SpendDetail, enabling buyer-supplier pairs to convey detailed information on spend that does not fit within TravelDetail, FeeDetail, or LaborDetail. Extrinsic elements are intended to provide additional machine-readable information. They extend the cXML protocol to support features not required by all implementations. The cXML specification does not define the content of Extrinsic elements. Each buyer-supplier pair must agree on and implement their definitions of Extrinsic elements.

New TimeCard Element

Timecards for temporary employees can now be transmitted by cXML. The TimeCard element documents hours worked, dates worked, and pay rates. Two new requests contain the TimeCard element: TimeCardInfoRequest, which allows buyers to send time cards to suppliers or staffing agencies, and TimeCardRequest, which allows suppliers and staffing agencies to send timecards to buyers.

New LeadTime Element

ItemDetail now contains an optional LeadTime element which describes the number of days needed for the buyer to receive the product in question. In an IndexItemAdd element, duplicate LeadTime information might come from both ItemDetail, where it is optional, and IndexItemDetail, where it is mandatory. If LeadTime elements are defined in both cases, then they should be identical.

Limited Changes in Use of UnitOfMeasure and UnitRate

In the context of an InvoiceDetailServiceItem element or a LaborDetail element, UnitOfMeasure and UnitPrice are deprecated in cXML 1.2.011, and should not be used. Use UnitRate instead, because it includes the rate code. For some services, such as temporary labor, UnitRate is required.

New preferredLang Attribute

The Email element now contains an optional preferredLang attribute. This attribute allows optional language information to be associated with email addresses so that email messages are constructed in the preferred language.

SearchDataElement Change

A change to SearchDataElement allows suppliers producing catalog content to specify the searchable type name without being forced to specify additional searchable information about the item. Formerly, it was <!ELEMENT SearchGroupData (Name, SearchDataElement+)>. Now, it is <!ELEMENT SearchGroupData (Name, SearchDataElement*)>.

New inspectionDate Attribute

You can now specify inspection dates for invoice lines using a new optional attribute called inspectionDate, which has been added to the InvoiceDetailItem, InvoiceDetailServiceItem, and InvoiceDetailOrderSummary elements. The inspectionDate attribute represents the date when the transfer of goods or the delivery of services occurs according to legal tax definitions. In most locations, use of this attribute is optional.

Followup Element Deprecated

As of cXML 1.2.011, the use of the Followup element is strongly discouraged. In early implementations, Followup was used to specify the URL to which future StatusUpdateRequest documents should be posted.

All cXML implementations should use the more robust Profile transaction to retrieve and convey information about server capabilities, including supported cXML version, supported transactions, and options to those transactions. See “Profile Transaction” on page 24 for more information.

1.2.009

Better Support for Change Orders

Previously, there was no uniform way to denote the version of change orders. Some implementations added a version number to the order number, such as -V2.

Now, cXML has better support for change orders through two new OrderRequestHeader attributes.

New SerialNumber Element in Invoices

The invoice InvoiceDetailItemReference serialNumber attribute has been deprecated and replaced with a repeating SerialNumber element.

This change enables suppliers to uniquely identify multiple items with serial numbers per invoice line item. The number of SerialNumber elements should match the invoice quantity.

New isRequiredForOrdering Attribute

Catalog type definition TypeAttribute elements can use a new attribute named isRequireForOrdering:

Catalog fields with this attribute cause procurement applications to require requisitioners to enter a value for the field before allowing the item into requisitions.

New Elements for Service Invoices

InvoiceDetailRequest documents now have better support for invoicing for supplied services. Previously, invoices did not capture all of the information mandated by the diverse requirements of service invoicing.

• InvoiceDetailServiceItem
  Describes a service being invoiced at a detailed level. Includes InvoiceDetailServiceItemReference, which identifies the master agreement that defines the service.
  
• Period
  A new element available within InvoiceDetailRequestHeader and InvoiceDetailOrderSummary that specifies the period during which the invoiced service was rendered.

Enhanced VAT Support in Invoices

InvoiceDetailRequest documents now have better support for specifying VAT (value added tax) information mandated by some European countries. The following new VAT features can be specified within TaxDetail elements at either the invoice header level or the line-item level.

• isTriangularTransaction
  Indicates that a transaction occurs between three parties in three different countries when the movement of goods does not follow the invoicing route.
  
• taxPointDate
  Specifies the date on which VAT becomes due.
  
• paymentDate
  Specifies the date on which payment must be made (used only for transactions in France).
  
• TriangularTransactionLawReference
  Specifies the relevant EU law covering the transaction VAT.

In addition, subsequentBuyer is a new Contact role that allows for identifying subsequent buying organizations in triangular transactions.

Direct PunchOut

Direct PunchOut is a new cXML capability that can reduce the time it takes clients to display the first page of a PunchOut site during PunchOut session initiation.

It enables clients to send cXML PunchOutSetupRequest documents directly to PunchOut sites for authentication, without first going through a network commerce hub for authentication and forwarding.

New Authentication Methods

Direct PunchOut is made possible by two new authentication methods available in cXML:

• MAC Authentication — The server interprets a Message Authentication Code (MAC) in the Sender credential in PunchOutSetupRequest documents.
  
  
• Auth Transaction — The server asks a network commerce hub to authenticate the client’s digital certificate and caches the response for subsequent PunchOut requests.

Servers indicate which authentication method they support through their cXML Profile.

New ProfileResponse PunchOutSetupRequest options

Servers indicate that they support direct PunchOut and specify the authentication methods they support by including the following new options for PunchOutSetupRequest in ProfileResponse documents.

<Transaction requestName="PunchOutSetupRequest">
   <URL>https://service.ariba.com/AN/cxml</URL>
   <Option name="Direct.URL">https://bigsupplier.com/punchout</Option>
   <Option name="Direct.AuthenticationMethod.CredentialMac">Yes</Option>
   <Option name="Direct.AuthenticationMethod.Certificate">Yes</Option>

New MAC Authentication Method

A new document authentication method uses Message Authentication Codes (MACs) to allow the authentication of documents sent directly from a client to a server without passing through a trusted third party (such as a network commerce hub). These documents contain a credential with an authentication code that can be interpreted only by the trusted third party and the receiving server, not by the sender.

A MAC conveys a receiver’s shared secret without revealing it to senders by encoding it through a hash.

MACs combine specific data with the receiver’s shared secret and they are computed with the HMAC-SHA1 algorithm described in IETF RFC 2104, “HMAC: Keyed-Hashing for Message Authentication”.

Direct PunchOut is a transaction that relies on MAC authentication.

New ProfileResponse Options

To support the communication of MACs from trusted third parties (such as network commerce hubs) to clients, there are new options for the ProfileResponse document:

<ProfileResponse>
   <Option name="CredentialMac.type">FromSenderCredentials</Option>
   <Option name="CredentialMac.algorithm">HMAC-SHA1-96</Option>
   <Option name="CredentialMac.creationDate">2003-01-15T08:42:46-0800</Option>
   <Option name="CredentialMac.expirationDate">2003-01-15T11:42:46-0800</Option>
   <Option name="CredentialMac.value">cR6Jpz58nriXERDN</Option>

New CredentialMac Element

To support the communication of MACs from senders to receivers, a new CredentialMac element has been added to the Credential element:

<Sender>
   <Credential domain=”NetworkId”>
      <Identity>AN9900000100</Identity>
      <CredentialMac type=”FromSenderCredentials”
            algorithm=”HMAC-SHA1-96”
            creationDate=”2003-01-15T08:42:46-0800”
            expirationDate=”2003-01-15T11:42:46-0800”>
         cR6Jpz58nriXERDN
      </CredentialMac>
      <UserAgent>Procurement System 2.0</UserAgent>
   </Credential>
</Sender>

New Auth Transaction

The Auth transaction is a new method for validating organizations’ credentials through a mutually trusted third party. It should be used to authenticate received documents that do not contain either a cXML shared secret or a MAC. The receiver encloses the credential of the sender (the principal) in an AuthRequest document and sends it to the trusted third party for validation.

If the principal attempts to authenticate using a client digital certificate, the receiver includes both the principal’s credential and information about the principal’s certificate in the AuthRequest document. (The receiver obtains this certificate information from its Web server or SSL/TLS implementation.)

If the credential (and optional certificate) authenticates, the trusted third party responds with a positive AuthResponse that contains the validated credential.

The receiver can cache the results of the Auth transaction until the expiration date indicated in the AuthResponse. During this period, if the principal presents the same credential and certificate, the receiver need not send another AuthRequest.

Status Code Clarification

Response status codes 200 and 201 have changed slightly and two new codes, 280 and 281, are introduced:

• 200 The request has been successfully delivered to the final recipient. You will receive no further status updates, unless an error occurs during later processing.
  
• 201 The request has been accepted for forwarding by an intermediate hub, or has been accepted by its ultimate destination and not yet been examined. You will receive updates on the status of the request, if a mechanism to deliver them is available.
  
• 280 The request has been forwarded by an intermediate hub. You will receive at least one more status update. This status could mean that the request was delivered to another intermediary or to the final recipient with 201 status, or that it was forwarded via a reliable non-cXML transport.
  
• 281 The request has been forwarded by an intermediate hub using an unreliable transport (such as email). You might receive status updates; however, if you do not received status updates, there is not necessarily a problem.

1.2.008

Added Type Definitions

Type definitions are a new document type used to describe supplemental catalog attributes and parametric data fields for catalogs. The new Type element replaces the deprecated SearchGroup element.

Type definitions provide a richer and more general framework for defining parametric types, and they allow the definition and standardization of parametric types from type provider organizations independent of catalog index data in which SearchGroup elements resided.

The SearchGroupData and SearchDataElement elements continue to specify the actual parametric data for a given catalog item. SearchGroupData must reference a defined type, and SearchDataElement specifies data for each type attribute within that type.

The TypeDefinition document is defined in a new cXML DTD named Catalog.dtd.

Added Catalog loadmode Attribute

The Index element has a new attribute named loadmode, which can be set to either "Full" or "Incremental" to indicate whether the catalog should be loaded into the target application as a complete catalog or an incremental change.

Previously, all cXML catalogs were incremental.

Added Ad-Hoc Item Flag

The ItemOut element in purchase orders has a new attribute named isAdHoc, which indicates that the item is a non-catalog (ad-hoc) item.

Non-catalog items are items entered manually by requisitioners, not items selected from electronic catalogs. Often, these items do not have part numbers. Non-catalog orders usually require special validation and processing.

Users enter non-catalog items to purchase products and services on an ad-hoc basis or because they could not find them in electronic catalogs.

If isAdHoc="yes" exists for some items and not for others, the requisition should be broken into two requisitions: one for catalog items and one for non-catalog items. Suppliers will then be able to automatically process as many requisition items as possible, instead of having to manually process both catalog and non-catalog items.

Added Backordered Flag

Suppliers can now issue ConfirmationRequest documents to indicate that items are back ordered.

The new type="backordered" attribute value can be used in either ConfirmationHeader for the entire order or in ConfirmationStatus for individual line items.

Contract Element Deprecated

The Contract element for defining contract pricing is deprecated. It is no longer needed, because MasterAgreementRequest documents can handle most of the requirements of contract pricing.

SearchGroup Element Deprecated

The SearchGroup element for defining parametric data categories is deprecated. It is no longer needed, because the new TypeDefinition element defines parametric data categories.

Note that catalogs continue to use the SearchGroupData element to populate parametric data.

1.2.007

InvoiceDetail Documentation

The InvoiceDetail transaction is now fully described in Chapter 9, "Invoices" in the cXML User's Guide.

version Attribute Deprecated

The version attribute of the cXML wrapper element has been deprecated. This attribute is not needed, because applications can detect the cXML version from the system identifier in the DOCTYPE declaration.

InvoiceStatus Added to StatusUpdateRequest

StatusUpdateRequest documents can contain a new element named InvoiceStatus. Buying organizations can now use these documents to update the status of invoices on commerce network hubs, which can forward them to suppliers. Invoice status can be reconciled, rejected, or paid.

The new InvoiceStatus element can contain a new PartialAmount element, which specifies the amount paid against the InvoiceDetailRequest. If this element exists, the buying organization does not pay the full amount specified within the InvoiceDetailRequest.

Multiple Provider URLs Returned by ProfileRequest

The Profile transaction can now return multiple variations of a single transaction type. Previously, if a cXML server supported multiple variations of a transaction, there was no standard for distinguishing them.

For example, a marketplace might provide two services within the ProviderSetupRequest transaction: signin and console. The ProfileResponse document can now specify the location of each variation:

<Transaction requestName="ProviderSetupRequest">
  <URL>http://service.hub.com/signin</URL>
  <Option name="service">signin</Option>
</Transaction>

<Transaction requestName="ProviderSetupRequest">
  <URL>http://service.hub.com/console</URL>
  <Option name="service">console</Option>
</Transaction>

Contact Role Enhancements for Compatibility with EDI

To enable easier data translation between EDI and cXML documents, there are new values for the Contact role attribute and the IdReference domain attribute.

• IdReference within InvoicePartner has a new Contact role: issuerOfInvoice. The from role has been deprecated.
• InvoiceDetailShipping has a new Contact role: carrierCorporate.
• The general Contact element has new roles: supplierCorporate and buyerCorporate. In addition, the general Contact roles from and to have been reserved for possible use in the future.

1.2.006

New InvoiceDetail.dtd

The InvoiceDetail transaction was added to support detailed invoicing. This transaction enables suppliers to invoice buying organizations through network commerce hubs for the entirety or portion of single or multiple orders. This transaction introduces the InvoiceDetailRequest document and uses a standard cXML Response document.

Use this transaction to inform buying organizations of invoice details, including order references, line item references, partners involved, accounting and financing, discount terms, shipping and special handling, applicable taxes, deposit and payment, and contact and remittance information. Use InvoiceDetail to send an invoice for any portion of all or selected line items from single or multiple orders. You can also use InvoiceDetail to send a credit or debit memo, or a duplicate copy of invoices sent earlier.

1.2.005

Added addressID Attribute to Contact

This attribute supports address codes for relationships that require id references.

Added TaxDetail Element to Tax

Tax element can contain repeatable TaxDetail elements. TaxDetail provides information regarding taxable amount, tax amount, tax location, tax purpose, tax category, tax rate, whether the tax is VAT recoverable, and textual description.

Added MasterAgreementRequest Transaction

Provides the capability of negotiating and creating Master Agreements with suppliers and creating Release Orders from these Master Agreements. Master Agreement documents can be routed from a procurement application to a supplier via a network hub.

Significant MasterAgreementRequestHeader Elements and Attributes Are:

• type attribute - Whether this document refers to a 'value' or 'quantity' Master Agreement
• agreementDate attribute - Date the Master Agreement becomes available for ordering
• expirationDate attribute - Date the Master Agreement expires and is no longer available for ordering
• MaxAmount element - Maximum amount for all line items on the Master Agreement
• MinAmount element - Committed amount for all line items on the Master Agreement

Significant AgreementItemOut Elements and Attributes Are:

• MaxAmount element - Maximum amount for this line item
• MinAmount element - Committed amount for this line item
• maxQuantity - Maximum quantity for this line item
• minQuantity - Committed quantity for this line item

Added orderType, agreementID, and agreementPayloadID Attributes to OrderRequest

orderType indicates whether the Order Request is a Release Order from an existing Master Agreement contract. The default is regular.

agreementID identifies the associated agreement corresponding to the Release Order.

agreementPayloadID specifies the PayloadID of the referenced Master Agreement.

Added agreementItemNumber Attribute to ItemOut

Identifies the corresponding item on a particular Master Agreement.

Added Elements and Attributes to Support RFQ (Request For Quote)

When initiating a PunchOut session for sourcing an item rather than extending a catalog search to the PunchOut site, some additions to the PunchOutSetupRequest and related documents improve the application integrations. These additions should be used only when the originating application is sure the destination supports them. They are not completely compatible with existing PunchOut destinations.

Added "source" operation to PunchOutSetupRequest

The operation attribute of the PunchOutSetupRequest now has an additional option in its enumeration. This allows a procurement application to begin a PunchOut session with reference to information present in the ItemOut element list rather than the SelectedItem element. Otherwise, the new operation is very similar to a "create" operation.

Added SupplierList Element to ItemOut

This new element may be used instead of a single SupplierID in the ItemOut element. SupplierList element defines a list of suppliers that might be associated with a sourced item. The ItemOut elements may specify a list of suppliers that could be involved in the sourcing process. The Supplier List needs the name and the list of SupplierIDs for that particular supplier.

Added SourcingStatus Element to PunchOutOrderMessageHeader and StatusUpdateRequest

Transfers information for the update of a given RFQ transaction, including the type of update. The content of the element can be a textual description of the update, such as the actual status update string used in the UI for display.

Added quoteStatus Attribute to PunchOutOrderMessage

Specifies whether the quote is still pending or final. This is a replacement for various hacks used to prevent submission of requisitions that include unfinished quotes. If set, the application should return for updates prior to allowing submission.

Corrected the Fixed Value of an a-dtype Attribute

The datatypes of the ProfileResponse attributes as expressed in the a-type fixed attribute of that element were incorrect in the 1.2.004 DTD. This was a regression of the defect mentioned below as fixed in 1.2.003.

Added itemDetailsRequired Attribute to Node

Indicates that a node would like the ItemDetails element returned in a later PunchOut (edit or inspect) operation. Without this, most procurement applications today default to sending only limited identification information such as the SupplierID, Path and ItemID elements.

This is an extension to the Path Routing feature mentioned in the 1.2.003 notes below.

Added DataAvailableMessage Element

A new message option for use within the GetPendingResponse. Indicates new information is available at the target site.

Moved InternalID Element Definition

Identifies a subscription or any available data.

1.2.004

Added PaymentStatus element to StatusUpdateRequest

This optional element allows more detailed information if the original document is a ConfirmationRequest with type="RequestToPay".

Added ProfileResponse lastRefresh Attribute

The lastRefresh attribute indicates when the server's profile cache last changed. When an application receives a ProfileResponse from a profile caching entity such as a network commerce hub, it will know the age of the data in the cache.

1.2.003

Added Path Routing Feature

Path Routing enables documents to be routed by and copied to intermediary systems such as direct and indirect marketplaces, and commerce service providers. In complex relationships between buyers and suppliers, documents might be routed through several intermediary systems before they reach the end node.

Added an optional Path element to the Header and Item level of cXML documents.

Corrected Datatype of ProfileResponse effectiveDate Attribute

Changed

a-dtype NMTOKENS #FIXED 'effectiveDate dateTime'

to

a-dtype NMTOKENS #FIXED 'effectiveDate dateTime.tz'

1.2.002

Added Catalog Upload Transaction

The cXML Catalog Upload transaction enables suppliers to programmatically upload and publish catalogs to a network hub. It can be used to automatically distribute updated catalogs whenever the pricing or availability of products or services changes. The Catalog Upload transaction consists of two cXML documents: CatalogUploadRequest and generic Response. CatalogUploadRequest was added to cXML.dtd.

The Catalog Upload transaction supports both CIF and cXML catalogs.

1.2.001

Added Provider PunchOut Transaction

ProviderSetupRequest, ProviderSetupResponse, and ProviderDoneMessage were added to the cXML.dtd. Provider PunchOut enables an application to punch out to a provider’s application that supplies some service to the originating application, such as credit card validation, single login, or self registration.

Moved Common PunchOut Related Element Definitions

Moved common PunchOut related element definitions to Base.mod from other modules thereby reordering the definitions within cXML.dtd and Fulfill.dtd.

Reordered cXML.dtd

Reordering of cXML.dtd  places the contents of Entities.mod and Profile.mod slightly later in the concatenation.

New Fulfill.dtd

• Added CopyRequest transaction.

• Reordering of the content models for elements used within the ConfirmationRequest and ShipNoticeRequest documents places lower-level lists at the end of each. For example, the ConfirmationStatus list moves to the end of the ConfirmationItem element. The content of ShipNoticePortion has also changed.

• New comments for many elements in ConfirmationRequest about defaulting and overriding behavior when a later document arrives with line-level rather than header-level data, or visa versa. Specifically describes which elements and attributes in the ConfirmationHeader apply to an entire order rather than this specific confirmation.

• Added requestToPay option in the enumeration for the type attributes of the ConfirmationHeader and ConfirmationStatus elements. This addition enables support for a scaled-down Invoice capability.

1.2.000

Added Extrinsic Element to PunchoutDetail

The PunchoutDetail element can now contain an Extrinsic list. This is used in a IndexItemPunchout (also correct with that capitalization) element in a static catalogue.

Added ConfirmationRequest and ShipNoticeRequest

Released a draft version of Fulfill.dtd containing ConfirmationRequest and ShipNoticeRequest.

1.1.010

Added CopyRequest Element

The CopyRequest element enables copying and forwarding of messages to new recipients, similar to forwarding an e-mail messages. To accomplish this, a new message is created and sent that includes the original message. It is primarily used by commerce network hubs and marketplace hosts.

Added Comments to Country-Related Elements and Attributes

Better explanations of the country-related elements and attributes have been added to the CountryCode element, and the isoCountryCode attribute on the Address, Country, and CountryCode elements.

1.1.009

Change in Data Type of role Attribute of Contact Element

The data type of the of the Contact element's optional role attribute has been changed from an enumeration containing endUser, administrator, purchasingAgent, technicalSupport, customerService, and sales, to a string with the same allowed values. This change enables the usage of the Contact element to be more easily expanded.

Addition of a lastChangedTimeStamp Attribute to the Identity Element

An optional lastChangedTimestamp attribute has been added to the Identity element. This attribute enables automatic synchronization of data between systems.

Addition of a domain Attribute to the InternalID Element

An optional domain attribute has been added to the InternalID element and provides scoping for this subscription catalogue identifier. The default domain value is "NetworkSubscription".

Addition of a DocumentReference Element to the OrderRequestHeader Element

An optional DocumentReference element has been added to the OrderRequestHeader element. DocumentReference provides explicit links between an update or delete action and the most recent OrderRequest for the same order. DocumentReference contains the payloadID of the most recent OrderRequest document in the list, not always the original OrderRequest (with type set to "new").

Definitions Rearranged

DocumentReference and StatusUpdateRequest have been moved to new locations within the cxml.dtd file. The constituent file status.mod no longer exists.

1.1.008

New Entity for cXML Version

The cXML version string (for example, 1.1.008) is now stored in a single-parameter entity named cxml.version. You can use this new entity to keep the version number consistent throughout cXML documents. For example,

<!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.1.008/cXML.dtd">
<cXML version="&cxml.version;" payloadID="992662" xml:lang="en-US" timestamp="2000-03-12T18:39:09-08:00">

Using this technique is not recommended when interacting with non-validating XML parsers. Non-validating parsers will have no version information as they load the cXML document, and will behave as if the version attribute were absent.

SGML Entity-Redefinition Conditionalized

cXML 1.1 followed a general XML recommendation to redefine five entities (lt, gt, amp, apos, and quot) for interoperability with SGML parsers. However, it was found that these redefinitions cause some XML parsers to complain.

These redefinitions are now conditionalized for better compatibility with XML parsers. In the future, commerce network platforms might have an option for setting the XML flag SGML-help to trigger these redefinitions for interoperability with SGML parsers.

Transaction Definitions Rearranged

The definitions of the %cxml.messages, %cxml.requests, and %cxml.responses entities have been moved to a separate module (Entities.mod) for improved maintainability. By moving these definitions to Entities.mod, they appear together within the .dtd, separate from their uses in the Message, Request, and Response elements.

New License Agreement

The copyright notice in the .dtd and .mod files has been replaced by a reference to the license agreement on www.cXML.org:

For cXML license agreement information, please see
http://www.cxml.org/home/license.asp

1.1.007

Deterministic Declaration of cXML Element

The top-level cXML element has a new declaration:

Old element type declaration:
   <!ELEMENT cXML ((Header, Message) | (Header, Request) | (Response))>

New declaration:
   <!ELEMENT cXML ((Header, (Message | Request)) | Response)>

The new declaration uses a deterministic grammar that is compatible with more XML parsers.

OrderReference Changed to DocumentReference

The proposed element name OrderReference was changed to DocumentReference so that it is more generic.

Less Restrictive Data Type for Attributes

The data types of the following attributes have been changed from NMTOKEN to CDATA so that they can contain less restrictive data:

isoCountryCode
currency
alternateCurrency
xml:lang

 

March 2009

Back to Top