cXML Release Notes
This document describes the changes between versions of cXML. For complete descriptions of all changes, see the cXML User's Guide.
ItemOut element now includes the
element to specify tolerances in purchase orders. This element allows buyers to specify line item quantity tolerance for individual purchase orders or different line items in a purchase order they send from their order management system. The tolerances specified in the purchase order are applied when a supplier creates ship notices against the purchase order. The
Tolerances element contains the
ShipTo element now includes the
element to specify the transport information in purchase orders or ship notices. The
TransportInformation element contains the
ShipNoticeHeader elements now include the
TermsofDelivery element to send delivery information at the header level in purchase orders or ship notices.
This element can also be added in the
ItemOut element or the
ShipNoticeItem element to send a purchase order or ship notice with delivery information at the line-item level.
TermsofDelivery element has the following elements:
ShipNoticeHeader element now includes a new
shipmentType attribute to specify if the type of ship notice is actual or estimated.
IdReference and Comments Elements
ShipNoticeHeader element now includes the
to specify additional information in the ship notices.
ShipmentIdentifier element now includes the
trackingNumberDate attribute that can store the tracking date provided by your carrier.< /p>
Total element now includes the
Modifications element to store any modification to the original price or shipping price of the item at the header level. This element can store a set of one or more
Modification elements and contains the following elements:
Modification element is also included in the
QuoteRequest element now includes details on the requests for quotations sent by the buyer to the sourcing application.
QuoteRequestHeader element has the following attributes:
QuoteRequestHeader element has the following elements:
QuoteItemOut element stores details on the line items sent in a QuoteRequest element.
QuoteItemOut element has the following attributes:
QuoteItemOut element has the following elements:
QuoteMessage element is used by the sourcing application to send quotes to the buyer.
QuoteMessageHeader element has the following attributes:
QuoteMessageHeader element has the following elements:
QuoteItemIn element stores details on the line items in a
This element has the following attributes:
QuoteItemIn has the following elements:
PriceBasisQuantity element is included in the
element in purchase orders, blanket purchase orders, and order confirmations and in the
InvoiceDetailServiceItem elements in invoices.
itemType and parentLineNumber Attributes
parentLineNumber attributes are now included in the following elements:
TaxDetail element now includes
Extrinsic element so additional tax-related
information can be included.
TaxDetail also includes a
new attribute, exemptDetail.
exemptDetail attribute allows specification of why
an item has no tax.
Tax element now includes an
element for additional tax-related information.
StatusUpdateRequest element now includes
Extrinsic element. This can be used for additional
information about the status of the document being updated.
A new transaction,
SubscriptionStatusUpdateRequest, is now included in Catalog Subscriptions.
InvoiceDetailRequestHeader element now includes the
invoiceOrigin attribute for invoice categorization purposes.
Expense Extrinsics for TimeCards
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 element now supports extrinsics. The
CorrectedSupplierBankAbaNumber extrinsics allow buyers to validate bank account information entered by suppliers.
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
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
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
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 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.
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.
New Correspondent Element in Headers
cXML documents can identify unknown sending or receiving organizations with a
Correspondent element. This element can appear in the
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
to specify the type of PunchOut available:
product. Procurement applications can display
these items differently to indicate the type of PunchOut available.
Scheduled Payment Document
Scheduled payment (
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
element to identify invoices in
StatusUpdateRequest documents. This element
identifies invoices by
invoiceDate. Previously, buying organizations
could identify invoices only by
New Data Download Transaction
The data download transaction (
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
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
PCard element has been added to the
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
Contact elements within the
Buying organizations can use this value to specify suppliers’ remittance
New Description Element Added to Invoice SpecialHandlingAmount
SpecialHandlingAmount element has a new
Description element. Suppliers can use this element to describe
the reason for the special handling charge.
Buyer and supplier organizations should now use attachments to
fulfill copy requests. In cXML 1.2.011, the use of the
as a child of
CopyRequest is deprecated. Instead, use the
element to attach another cXML document, whether or not it contains attachments
New PaymentRemittance Transaction
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
and suppliers respond with generic response documents. When payment transaction
status levels are updated, procurement applications send
InvoiceDetailPaymentTerm is deprecated in cXML 1.2.011,
in favor of
PaymentTerm (described below). cXML implementations
for payment should use
New PaymentTerm Element
Defines the payment term in orders and invoices. This deprecates
InvoiceDetailPaymentTerm previously defined.
defines either the net term (without discount) or the discount term (with discount).
Digital Signature Support
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
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
in addition to the
TravelDetail contains information about travel
line items for air, car rental, hotel, and rail in
ItemOut elements. In addition, cXML 1.2.011 supports the use
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
"delete", which can be sent to a travel booking
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 of
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
but could be described in
LaborDetail contains information about an item
related to temporary labor.
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
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
New TimeCard Element
Timecards for temporary employees can now be transmitted by cXML.
TimeCard element documents hours worked, dates worked, and
pay rates. Two new requests contain the
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
element which describes the number of days needed for the buyer to receive the
product in question. In an
IndexItemAdd element, duplicate
information might come from both
ItemDetail, where it is optional,
IndexItemDetail, where it is mandatory. If
elements are defined in both cases, then they should be identical.
Limited Changes in Use of UnitOfMeasure and UnitRate
In the context of an
are deprecated in cXML 1.2.011, and should not be used. Use
instead, because it includes the rate code. For some services, such as temporary
UnitRate is required.
UnitRate represents the amount to be paid per unit of time (or of
some other measure). In the case of multiple
should include a
TermReference to distinguish it from others.
is a generic base element that identifies the definition of the
New preferredLang Attribute
Email element now contains an optional
attribute. This attribute allows optional language information to be associated
with email addresses so that email messages are constructed in the preferred
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
SearchGroupData (Name, SearchDataElement+)>. Now, it is
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
InvoiceDetailOrderSummary elements. The
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
is strongly discouraged. In early implementations,
used to specify the URL to which future
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.
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
Specifies the order version number of change orders,
starting with "1" for the original order.
|Indicates whether the order includes changes that are
relevant only within the buying organization. For example, a minor change
was made that does not affect information used by the supplier. Suppliers
might not see internal order versions, depending on their customers' configuration.
New SerialNumber Element in Invoices
attribute has been deprecated and replaced with a repeating
This change enables suppliers to uniquely identify multiple items with serial
numbers per invoice line item. The number of
should match the invoice quantity.
New isRequiredForOrdering Attribute
Catalog type definition
TypeAttribute elements can use a new attribute
|Indicates that the value for an attribute must be provided
(usually by the requisitioner) before the item can be included in an order
for the supplier. Typically used for ad-hoc or partially specified catalog
Catalog fields with this attribute cause procurement applications to require
requisitioners to enter a value for the field before allowing the item into
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.
Describes a service being invoiced at a detailed level. Includes
which identifies the master agreement that defines the service.
A new element available within
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.
Indicates that a transaction occurs between three parties in three different
countries when the movement of goods does not follow the invoicing route.
Specifies the date on which VAT becomes due.
Specifies the date on which payment must be made (used only for transactions
Specifies the relevant EU law covering the transaction VAT.
subsequentBuyer is a new
that allows for identifying subsequent buying organizations in triangular transactions.
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
It enables clients to send cXML
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
- MAC Authentication The server interprets a Message Authentication
Code (MAC) in the Sender credential in
- Auth Transaction The server asks a network commerce hub
to authenticate the clients digital certificate and caches the response
for subsequent PunchOut requests.
Servers indicate which authentication method they support through their cXML
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
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
A MAC conveys a receivers shared secret without revealing it to senders
by encoding it through a hash.
MACs combine specific data with the receivers 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
New CredentialMac Element
To support the communication of MACs from senders to receivers, a new
element has been added to the
<UserAgent>Procurement System 2.0</UserAgent>
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
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 principals credential and information
about the principals certificate in the
(The receiver obtains this certificate information from its Web server or
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
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
- 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.
Added Type Definitions
Type definitions are a new document type used to describe supplemental catalog
attributes and parametric data fields for catalogs. The new
element replaces the deprecated
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
SearchGroup elements resided.
continue to specify the actual parametric data for a given catalog item.
must reference a defined type, and
data for each type attribute within that type.
TypeDefinition document is defined in a new cXML DTD named
Added Catalog loadmode Attribute
Index element has a new attribute named
which can be set to either
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
ItemOut element in purchase orders has a new attribute named
isAdHoc, which indicates that the item is a non-catalog (ad-hoc)
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.
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.
type="backordered" attribute value can be used
ConfirmationHeader for the entire order or in
for individual line items.
Contract Element Deprecated
Contract element for defining contract pricing is deprecated.
It is no longer needed, because
can handle most of the requirements of contract pricing.
SearchGroup Element Deprecated
SearchGroup element for defining parametric data categories
is deprecated. It is no longer needed, because the new
element defines parametric data categories.
Note that catalogs continue to use the
to populate parametric data.
The InvoiceDetail transaction is now fully described in Chapter 9, "Invoices"
in the cXML User's Guide.
version Attribute Deprecated
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
InvoiceStatus element can contain a new
element, which specifies the amount paid against the
If this element exists, the buying organization does not pay the full amount
specified within the
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
transaction: signin and console. The
document can now specify the location of each variation:
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
InvoicePartner has a new
from role has
InvoiceDetailShipping has a new
- The general
Contact element has new roles:
buyerCorporate. In addition, the general
to have been reserved for possible
use in the future.
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.
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
provides information regarding taxable amount, tax amount, tax location, tax
purpose, tax category, tax rate, whether the tax is VAT recoverable, and textual
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
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
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
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
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
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.
Added PaymentStatus element to StatusUpdateRequest
This optional element allows more detailed information if the original document
Added ProfileResponse lastRefresh Attribute
lastRefresh attribute indicates when the server's profile
cache last changed. When an application receives a
from a profile caching entity such as a network commerce hub, it will know the
age of the data in the cache.
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
Corrected Datatype of ProfileResponse effectiveDate Attribute
a-dtype NMTOKENS #FIXED 'effectiveDate dateTime'
a-dtype NMTOKENS #FIXED 'effectiveDate dateTime.tz'
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 was added
The Catalog Upload transaction supports both CIF and cXML catalogs.
Added Provider PunchOut Transaction
ProviderDoneMessage were added to the
PunchOut enables an application to punch out to a providers 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
from other modules thereby reordering the definitions within
cXML.dtd places the contents of
Profile.mod slightly later in the concatenation.
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
ConfirmationItem element. The content of
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.
requestToPay option in the enumeration for the type
attributes of the
elements. This addition enables support for a scaled-down Invoice capability.
Added Extrinsic Element to PunchoutDetail
PunchoutDetail element can now contain an
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
Added CopyRequest Element
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
attribute on the
Change in Data Type of role Attribute of Contact Element
The data type of the of the
Contact element's optional
attribute has been changed from an enumeration containing
sales, to a string with the same
allowed values. This change enables the usage of the
to be more easily expanded.
Addition of a lastChangedTimeStamp Attribute to the Identity Element
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
domain attribute has been added to the
element and provides scoping for this subscription catalogue identifier. The
default domain value is "NetworkSubscription".
Addition of a DocumentReference Element to the OrderRequestHeader Element
DocumentReference element has been added to the
DocumentReference provides explicit
links between an update or delete action and the most recent
for the same order.
DocumentReference contains the
of the most recent
OrderRequest document in the list, not always
OrderRequest (with type set to "new").
StatusUpdateRequest have been
moved to new locations within the
cxml.dtd file. The constituent
status.mod no longer exists.
New Entity for cXML Version
The cXML version string (for example, 1.1.008) is now stored in a single-parameter
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"
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
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.responses entities have been moved to a separate module
Entities.mod) for improved maintainability. By moving these definitions
Entities.mod, they appear together within the .dtd, separate
from their uses in the
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
Deterministic Declaration of cXML Element
cXML element has a new declaration:
Old element type declaration:
<!ELEMENT cXML ((Header, Message) | (Header, Request)
<!ELEMENT cXML ((Header, (Message | Request)) |
The new declaration uses a deterministic grammar that is compatible with more
OrderReference Changed to DocumentReference
The proposed element name
OrderReference was changed to
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:
Back to Top