<?xml version="1.0" encoding="UTF-8"?>
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/modules/Common.mod#6 $
-->

<!--
    A few character entities the XML recommendation says should be defined
    "for interoperability" with existing SGML parsers.  By default, these
    are not included to avoid warnings (about entity redefinition) from
    many XML parsers.
-->
<!ENTITY % SGML-help "IGNORE">
<![%SGML-help;[
<!ENTITY lt     "&#38;#60;">
<!ENTITY gt     "&#62;">
<!ENTITY amp    "&#38;#38;">
<!ENTITY apos   "&#39;">
<!ENTITY quot   "&#34;">
]]>

<!--
    Common types used throughout the cXML definition.

    The types try to follow the XML DATA definition submitted to the W3C. See
    the following for more information,

        http://msdn.microsoft.com/xml/reference/schema/datatypes.asp
        http://www.w3c.org/TR/1998/NOTE-XML-data-0105/

-->

<!-- Atomic-level Types -->
<!ENTITY % bin.base64 "CDATA">
<!ENTITY % bin.hex "CDATA">
<!ENTITY % boolean "(0 | 1)">    <!-- 0 is false, 1 is true -->
<!ENTITY % char "CDATA">
<!ENTITY % date "CDATA">
<!ENTITY % datetime.tz "CDATA">  <!-- Time zone is required -->
<!ENTITY % fixed.14.4 "CDATA">
<!ENTITY % i8 "CDATA">
<!ENTITY % int "%i8;">
<!ENTITY % r8 "CDATA">
<!ENTITY % number "CDATA">       <!-- No limit on number of digits, unlike
                                      %r8; -->
<!ENTITY % string "CDATA">
<!ENTITY % time.tz "CDATA">      <!-- Time zone is required -->
<!ENTITY % ui8 "CDATA">
<!ENTITY % uint "%ui8;">         <!-- Unique to this specification -->
<!ENTITY % uri "CDATA">
<!ENTITY % uuid "CDATA">

<!-- Higher-level Types -->
<!--
    NOTE: The following is a temporary *hack* to allow empty values for
    some attributes with these types.  The nmtoken entity should resolve to
    NMTOKEN.
-->
<!ENTITY % nmtoken "CDATA">      <!-- Any combination of XML name chars. -->
<!ENTITY % isoLangCode "%nmtoken;">         <!-- ISO 639 Language Code -->
<!ENTITY % isoCountryCode "%nmtoken;">      <!-- ISO 3166 Country Code -->
<!ENTITY % isoCurrencyCode "%nmtoken;">     <!-- ISO 4217 Currency Code -->
<!ENTITY % xmlLangCode "%nmtoken;"> <!-- Language code as defined by XML
                                         recommendation: Language and
					 country. -->
<!ENTITY % URL "%uri;">
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/Modules/Base.mod#11 $
-->

<!--
    This file defines the basic elements used to build higher level
    constructs in cXML.
-->

<!-- Basic Name/Data Elements -->
<!--
    Name is used to provide an identifier for other elements.

    xml:lang
        The language in which the name is written.
-->
<!ELEMENT Name (#PCDATA)> <!-- string -->
<!ATTLIST Name
    xml:lang  %xmlLangCode;  #REQUIRED
>

<!--
    An Extrinsic is an element which can be used to extend the data
    associated with known elements.

    Since this Element is of type ANY, it could contain any arbitrary XML
    document within itself, or a binary ![CDATA[]] document.

    name
        Name used to identify this extrinsic.
-->
<!ELEMENT Extrinsic ANY>
<!ATTLIST Extrinsic
    name  %string;  #REQUIRED
>

<!--
    Description is a string which describes something.
    Though text may be interspersed with ShortName elements in this content
    model, placing the ShortName at the beginning or end of the element is
    much preferred.  At most one ShortName element is allowed per
    Description.  The intended content model would be more like
    (( ShortName, #PCDATA ) | ( #PCDATA | ShortName? )) if DTD syntax
    supported it.

    xml:lang
        The language in which the description is written.
-->
<!ELEMENT Description ( #PCDATA | ShortName )* > <!-- mixed: string and
                                                      ShortName -->
<!ATTLIST Description
    xml:lang  %xmlLangCode;  #REQUIRED
>

<!--
    A short string which describes something in fewer characters than the
    entire Description.  This should be used when limited space is available.
    For example, a table of elements might show the ShortName's of each.  A
    linked "details" view would show the entire Description (including the
    ShortName).  Without a ShortName, the user interface must default to a
    truncation of the Description.
    This element does not require an xml:lang attribute since it appears only
    within a Description element.  The language of the ShortName must match
    that of the surrounding Description.
-->
<!ELEMENT ShortName (#PCDATA)> <!-- string -->

<!-- Telephone Number Elements -->
<!--
    International ITU dial code for the country code in question.  This
    code would be entered after any escape code necessary to begin
    International dialing.  That is, the escape code does not appear in the
    content of this element.

    isoCountryCode
        The ISO 3166 2-letter country code for the dial code in question.
-->
<!ELEMENT CountryCode (#PCDATA)> <!-- uint -->
<!ATTLIST CountryCode
    isoCountryCode  %isoCountryCode;  #REQUIRED
>

<!--
    The areacode or city code within a CountryCode.
-->
<!ELEMENT AreaOrCityCode (#PCDATA)> <!-- uint -->

<!--
    The local number part of a telephone number.
-->
<!ELEMENT Number (#PCDATA)> <!-- string -->

<!--
    An extension within relative to the Number element. This element has no
    meaning without an associated Number element.
-->
<!ELEMENT Extension (#PCDATA)> <!-- uint -->

<!--
    TelephoneNumber represents international telephone numbers.
-->
<!ELEMENT TelephoneNumber (CountryCode, AreaOrCityCode, Number, Extension?)>

<!--
     Phone is a "named" TelephoneNumber.

     name
          specifies an identifier which indicates the type of phone number.
          US examples would include "work","home", etc.
-->
<!ELEMENT Phone (TelephoneNumber)>
<!ATTLIST Phone
    name  %string;  #IMPLIED
>

<!--
    Fax number.
-->
<!ELEMENT Fax (TelephoneNumber | URL | Email)>
<!ATTLIST Fax
    name  %string;  #IMPLIED
>

<!-- Addressing Elements -->
<!--
    URL. A string which represents a URL
-->
<!ELEMENT URL (#PCDATA)> <!-- URL -->
<!ATTLIST URL
    name  %string;  #IMPLIED
>

<!--
    An email address. Address must conform to RFC 821 (SMTP Standard).
-->
<!ELEMENT Email (#PCDATA)> <!-- string -->
<!ATTLIST Email
    name  %string;  #IMPLIED
>

<!--
    Contact represents an entity at a location. The nature of this
    element is that it represents a communication "end point" for a
    location.

    role
        Position this person or group plays in the procurement process.
        Likely values include endUser, administrator, purchasingAgent,
        technicalSupport, customerService, sales,
        supplierCorporate, supplierMasterAccount, supplierAccount,
        buyerCorporate, buyerMasterAccount, buyerAccount, buyer,
        subsequentBuyer. Other values may be allowed in some cases.

        from and to roles are reserved for future use.

    addressID
        An id for the address. Needed to support address codes for
        relationships that require id references.
-->
<!ELEMENT Contact (Name, PostalAddress*, Email*, Phone*, Fax*, URL*)>
<!ATTLIST Contact
    role             NMTOKEN           #IMPLIED
    addressID        %string;          #IMPLIED
>

<!--
    The DeliverTo part of an Address. This would be internal to the actual
    address know to the outside world. Similar to what an extension is to a
    TelephoneNumber.
-->
<!ELEMENT DeliverTo (#PCDATA)> <!-- string -->

<!--
    Street is a single line of an Address' location.
-->
<!ELEMENT Street (#PCDATA)> <!-- string -->

<!--
    City is the name of the city in an Address' location.
-->
<!ELEMENT City (#PCDATA)> <!-- string -->

<!--
    State is an optional state identifier in an Address' location.
-->
<!ELEMENT State (#PCDATA)> <!-- string -->

<!--
    PostalCode (I have no idea how to describe it)
-->
<!ELEMENT PostalCode (#PCDATA)> <!-- string -->

<!--
    Country is the name of the country in an Address' location.  The
    content of this element is a string which may (for example) be printed
    directly to a shipping label.  The content is the human-readable
    equivalent of the isoCountryCode used by applications.

    isoCountryCode
        The ISO 3166 2-letter country code for this country.
-->
<!ELEMENT Country (#PCDATA)> <!-- string -->
<!ATTLIST Country
    isoCountryCode  %isoCountryCode;  #REQUIRED
>

<!--
    PostalAddress is a real-world location for a business or person.
-->
<!ELEMENT PostalAddress (DeliverTo*, Street+, City, State?,
                         PostalCode?, Country)>
<!ATTLIST PostalAddress
    name  %string;  #IMPLIED
>

<!--
    Address is the association of a Contact and an Location.

    isoCountryCode
        The ISO 3166 2-letter country code for the country containing this
        location.

    addressID
        An id for the address.  Needed to support address codes for
        relationships that require id references.  An example would be a
        shipping code.
-->
<!ELEMENT Address (Name, PostalAddress?, Email?, Phone?, Fax?, URL?)>
<!ATTLIST Address
    isoCountryCode  %isoCountryCode;  #IMPLIED
    addressID       %string;          #IMPLIED
>

<!-- Financial Elements -->
<!--
    Money is the representation of the object used to pay for items.

    currency
        specifies the currency in which amount is stated, must conform to ISO
        4217 currency codes.

    alternateAmount
        the amount of money in the alternateCurrency. Optional and used to
        support dual-currency requirements such as the Euro.

    alternateCurrency
        specifies the currency in which the alternateAmount is stated, must
        conform to ISO 4217 currency codes.
-->
<!ELEMENT Money (#PCDATA)> <!-- number -->
<!ATTLIST Money
    currency           %isoCurrencyCode;  #REQUIRED
    alternateAmount    %number;           #IMPLIED
    alternateCurrency  %isoCurrencyCode;  #IMPLIED
>

<!--
    Optional textual child for communicating arbitrary comments or
    description along with the parent.
    Though text may be interspersed with Attachment elements in this content
    model, grouping the Attachment list at the begging or end of the element
    is much preferred.  The intended content model would be more like
    (( Attachment+, #PCDATA ) | ( #PCDATA | Attachment* )) if the DTD syntax
    supported it.

    xml:lang
        The language in which the Comments are written.  This attribute
    will be required in a future version of cXML.  (Leaving it out is
    deprecated.)
-->
<!ELEMENT Comments ( #PCDATA | Attachment )* > <!-- mixed: string and
                                                    opt. Attachment list -->
<!ATTLIST Comments
    xml:lang  %xmlLangCode;  #IMPLIED
>

<!--
    Optional child of Comments element referencing a part in a multipart MIME
    transmission.

    The contained URL must use the scheme "cid:".  This is the identifier for
    the referenced attachment within the larger transmission.  Must match the
    Content-ID header of one (and only one) part of the MIME transmission
    containing this cXML document.  May also be used to retrieve the
    attachment file separately.
-->
<!ELEMENT Attachment (URL)>

<!---
    Reference to a remote attachment. 

    AttachmentReference is used inside Extrinsic elements that have a
    predefined name of "Attachments".

    In the context of AttachmentReference, the domain attribute of
    InternalID is currently optional. However, as a way to prevent
    circular request paths, the sending application may use a
    predefined value of "local" to indicate that the attachment
    requested is local to the other application.
	
    length
        length of the attachment in bytes.
-->
<!ELEMENT AttachmentReference (Name, Description, InternalID)>
<!ATTLIST AttachmentReference
    length  %uint;  #IMPLIED
>

<!--
    Price per unit of item.
-->
<!ELEMENT UnitPrice (Money)>

<!--
    Reference to an earlier document (for example, OrderRequest).  In a
    StatusUpdateRequest, this element identifies the purchase order to be
    updated.

    payloadID
        A unique identifier for the document.  Copied directly from the
        cXML element of the original document.
-->
<!ELEMENT DocumentReference EMPTY>
<!ATTLIST DocumentReference
    payloadID       %string;      #REQUIRED
>

<!ELEMENT InternalID (#PCDATA)> <!-- string -->
<!ATTLIST InternalID
    domain   %string;  #IMPLIED
>

<!-- ====
    Common to most variants of the PunchOut transaction set.  Defined here
    to be easily shared between multiple DTD files without requiring
    inclusion of Transaction.mod in all of them.

    All of the PunchOut transaction sets include an originating Request
    (ProviderSetupRequest for example), relatively simple Response
    (PunchOutSetupResponse for example) and final Message
    (ProviderDoneMessage or PunchOutOrderMessage).  The Request and
    Response comprise a back-end transaction between two cooperating
    applications that wish to extend an interactive session from one to the
    other.  The Request provides the destination application with
    authentication, identification and other setup information.  The
    Response provides the originating application with a unique starting
    location for the interactive (HTML) session at the destination system.

    After receiving a Response of this type, the originating application
    redirects the user's browser to the provided location.  (For some
    non-HTML applications, opening a new browser window at that location
    may be more appropriate.)  The destination system eventually provides
    an HTML form to the user's browser.  This form submits the final
    Message to close the remote session, return that user to the
    originating application and carry any required information back to the
    originating application.
==== -->

<!--
    OriginatorCookie - Identification of a specific PunchOut session.  Used
    in both originating Request and later Message that returns user to
    originating application.

    Note: The BuyerCookie element used in a 'regular' PunchOut transaction
    (defined in Transaction.mod) is of type ANY.  That does not seem
    useful.  The string required below better matches the needs for this
    element.  Future transactions similar to the PunchOut transaction will
    use this element.
-->
<!ELEMENT OriginatorCookie (#PCDATA)>

<!--
    BrowserFormPost - Location to which the user's browser must submit the
    final Message.  This location (carried in the originating Request) does
    not need to be specific to a PunchOut session since the
    OriginatorCookie is returned in the Message.
-->
<!ELEMENT BrowserFormPost (URL)>

<!--
    SelectedService - Identification of a service offered by this provider
    and requested in this transaction.  Used only in the originating
    Request.
-->
<!ELEMENT SelectedService (#PCDATA)>

<!--
    StartPage - Location to which the user's browser must be redirected to
    begin the interactive portion of the session at the remote site.  The
    destination system returns this information in the Response document.
    This location must be specific to a particular session.  It is
    effectively a one time key, providing authenticated entry into the
    destination system.
-->
<!ELEMENT StartPage (URL)>

<!--
    ReturnData - Any information the originator must know about the
    completed operation at the provider site.  The ReturnValue is for
    applications; the Name is for human consumption (direct presentation in
    the User Interface of the application).  Where appropriate for the
    possible services, this element may appear in the final Message for a
    PunchOut session.

    name
        An identifier for the data returned.  Provides a meaning for the
        contents of a ReturnData element.
-->
<!ELEMENT ReturnData (ReturnValue, Name)>
<!ATTLIST ReturnData
    name  %string;  #IMPLIED
>

<!ELEMENT ReturnValue (#PCDATA)>
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/modules/Version.mod#4 $
-->

<!--
     Another top-level entity used in Transport.mod.  Defined here to allow
     easy updates to the release version of cXML without opening
     Transport.mod.  This should also provide an easy file to search for
     the current release version string.
-->

<!-- cxml.version
    Current default string for the cXML@version attribute.  Corresponds to
    the final directory of the SYSTEM identifier used in all up-to-date
    cXML documents.
    For easy parsing of this file, do not remove whitespace surrounding the
    actual version string.
-->
<!ENTITY cxml.version "1.2.009" >
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/Modules/Supplier.mod#7 $
-->

<!--
    Supplier of goods and services. Includes a list of SupplierIDs which
    identify the Supplier.

    corporateURL
        URL to web site about the supplier

    storeFrontURL
        URL to web site where a user can shop or browse
-->
<!ELEMENT Supplier (Name, Comments?, SupplierID+, SupplierLocation*)>
<!ATTLIST Supplier
    corporateURL   %URL;  #IMPLIED
    storeFrontURL  %URL;  #IMPLIED
>

<!--
    One of the locations for a supplier. Supplier location is
    generally a physical location.
-->
<!ELEMENT SupplierLocation (Address, OrderMethods)>

<!--
    OrderMethods is the list of methods by which one can order
    from a supplier. The contact element is the technical contact
    who should be able to assist with order processing issues.
    The list is to be ordered by supplier preference, the first
    element having the highest degree of preference.
-->
<!ELEMENT OrderMethods (OrderMethod+, Contact?)>

<!--
    OrderMethod is a method for ordering. It is comprised of a
    target address for the order and the protocol expected by
    the address.
-->
<!ELEMENT OrderMethod (OrderTarget, OrderProtocol?)>

<!--
    OrderTarget represents an address to which orders can be
    sent.
-->
<!ELEMENT OrderTarget (Phone | Email | Fax | URL | OtherOrderTarget)>

<!--
    OrderProtocol is the communication method to be used when
    communicating an order to a supplier. An example would be "cXML".
-->
<!ELEMENT OrderProtocol (#PCDATA)> <!-- string -->

<!--
    OtherOrderTarget represents an address which is not enumerated by
    default in the OrderTarget Element. This may contain address targets
    beyond the ability of this document to describe.

    name
        Optional name for target.
-->
<!ELEMENT OtherOrderTarget ANY>
<!ATTLIST OtherOrderTarget
    name  %string;  #IMPLIED
>

<!--
    Definition of a supplier id.  A supplier id is a (domain, value)
    pair so that suppliers have the flexibility to define their id's
    according to an arbitrary convention (e.g., (DUNS, 12345),
    (TaxID, 88888888)).

    domain
        the domain of the id
-->

<!ELEMENT SupplierID (#PCDATA)> <!-- string -->
<!ATTLIST SupplierID
    domain  %string;  #REQUIRED
>
<!--
   Defines a List of Suppliers that might be associated with a quote Item. Used in
   ItemOut. 
-->
<!ELEMENT SupplierList (Supplier+)>
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/modules/Item.mod#6 $
-->

<!--
    Must be a UN/CEFACT (Recommendation 20) unit of measure code.
-->
<!ELEMENT UnitOfMeasure (#PCDATA)> <!-- nmtoken -->

<!--
    ID with which the item's manufacturer identifies the item.
-->
<!ELEMENT ManufacturerPartID (#PCDATA)> <!-- string -->

<!--
    Name of the item's manufacturer.

    xml:lang
        The language in which the ManufacturerName is written.  This
    attribute will be required in a future version of cXML.  (Leaving it
    out is deprecated.)
-->
<!ELEMENT ManufacturerName (#PCDATA)> <!-- string -->
<!ATTLIST ManufacturerName
    xml:lang %xmlLangCode; #IMPLIED
>

<!--
    Classification is used to group items into similar categories.

    domain
        "name" of classification, ie., SPSC
-->
<!ELEMENT Classification (#PCDATA)> <!-- string -->
<!ATTLIST Classification
    domain  %string;  #REQUIRED
>

<!--
    How the supplier identifies an item they sell.

    If SupplierPartID does not provide a unique key to identify the item,
    then the supplier should generate a key which identifies the part
    uniquely when combined with the SupplierID and SupplierPartID. The
    key is called SupplierPartAuxiliaryID.

    An example is where a Supplier would use the same PartID for an
    item but have a different price for units of "EA" versus "BOX".
    In this case, the ItemIDs should be:
    <ItemID>
        <SupplierPartID>pn12345</SupplierPartID>
        <SupplierPartAuxiliaryID>EA</SupplierPartAuxiliaryID>
    </ItemID>
    <ItemID>
        <SupplierPartID>pn12345</SupplierPartID>
        <SupplierPartAuxiliaryID>
           <foo>well formed XML here</foo>
        </SupplierPartAuxiliaryID>
    </ItemID>
    In this case, the "foo" element must be defined in an internal subset
    sent with the cXML document.  Otherwise, parsers will not be able to
    validate that document.

    In a preferred approach, the sending application may escape the contained
    XML using CDATA sections.  This would appear as:
       ...
       <SupplierPartAuxiliaryID>
           <![CDATA[<foo>well formed XML here</foo>]]>
       </SupplierPartAuxiliaryID>
       ...

    Finally, the angle brackets could be escaped using XML character
    entities.  This might be a bit harder for humans to read.  For example:
       ...
       <SupplierPartAuxiliaryID>
           &lt;foo&gt;well formed XML here&lt;/foo&gt;
       </SupplierPartAuxiliaryID>
       ...
-->
<!ELEMENT SupplierPartID (#PCDATA)> <!-- string -->

<!ELEMENT SupplierPartAuxiliaryID ANY>

<!--
    A unique identification of an item. SupplierID is not required since
    ItemIDs never travel alone.
-->
<!ELEMENT ItemID (SupplierPartID, SupplierPartAuxiliaryID?)>

<!--
    ItemDetail contains detailed information about an item. All the data that
    a user would want to see about an item instead of the bare essentials
    that are represented in the ItemID.
-->
<!ELEMENT ItemDetail (UnitPrice, Description+, UnitOfMeasure,
                      Classification+, ManufacturerPartID?,
                      ManufacturerName?, URL?, Extrinsic*)>
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/Modules/Transaction.mod#18 $
-->

<!--
    For better definitions of these Elements/Entities, refer to the cXML
    Transaction Specification documents.
-->

<!-- Basic transactional elements used throughout -->
<!--
    The total for something.
-->
<!ELEMENT Total (Money)>

<!--
    The bill to for an item.
-->
<!ELEMENT BillTo (Address)>

<!--
    The ship to for a item.
-->
<!ELEMENT ShipTo (Address)>

<!--
    Definition of a cXML Shipping item. Represents a shipping cost in the
    shopping basket (PunchOutOrderMessage) or an order to the supplier
    (OrderRequest). There could be one of these for the entire order, or one
    per lineitem.

    trackingDomain
        represents the logistics supplier, I.E., "FedEx", "UPS", etc.

    trackingId
        an optional element value that represents the logistics supplier
        tracking number

    tracking
        Deprecated - Do Not Use
-->
<!ELEMENT Shipping (Money, Description)>
<!ATTLIST Shipping
    trackingDomain  %string;  #IMPLIED
    trackingId      %string;  #IMPLIED
    tracking        %string;  #IMPLIED
>

<!--
    Defines a Purchasing Card element used for payment
-->
<!ELEMENT PCard (PostalAddress?)>
<!ATTLIST PCard
    number      %number;  #REQUIRED
    expiration  %date;    #REQUIRED
    name        %string;  #IMPLIED
>

<!--
    The list of valid payment types.
-->
<!ENTITY % cxml.payment  "PCard">
<!ELEMENT Payment (%cxml.payment;)>

<!--
    Defines an accounting segment.  Segment is an older, deprecated way to
    transport this information.

    type
        The accounting type of this segment.

    id
        The unique key of this Segment against the type.

    description
        Textual description of the Segment. For human readability.
-->
<!ELEMENT Segment EMPTY>
<!ATTLIST Segment
    type         %string;  #REQUIRED
    id           %string;  #REQUIRED
    description  %string;  #REQUIRED
>

<!--
    Defines an accounting segment.  AccountingSegment is the newer, better
    way to transport this information.  Name corresponds to the type
    attribute of Segment; Description corresponds to description.  Both add
    required locale attributes to the strings.

    id
        The unique key of this Segment against the type.
-->
<!ELEMENT AccountingSegment ( Name, Description )>
<!ATTLIST AccountingSegment
    id           %string;  #REQUIRED
>

<!--
    An accounting object.  Use of the Segment element here is deprecated.

    name
        The name of the object containing the specified accounting segments.
-->
<!ENTITY % cxml.accounting  "( Segment+ | AccountingSegment+ )">
<!ELEMENT Accounting (%cxml.accounting;)>
<!ATTLIST Accounting
    name  %string;  #REQUIRED
>

<!--
    A charge against an Accounting element.
-->
<!ELEMENT Charge (Money)>

<!--
    The combination of a Charge against an Accounting Element. A distribution
    represents the breakdown of one overall amount into sub-amounts.
-->
<!ELEMENT Distribution (Accounting, Charge)>

<!ELEMENT TaxAmount (Money)>

<!ELEMENT TaxableAmount (Money)>

<!--
    One language-specific string for the location of tax,
    e.g. London, Canada, California, etc.

    xml:lang
        The language or locale in which the location of tax is written.
-->
<!ELEMENT TaxLocation (#PCDATA)>              <!-- string -->
<!ATTLIST TaxLocation
   xml:lang              %xmlLangCode;         #REQUIRED
>

<!--

    TriangularTransactionLawReference indicates the relevant law as
    titled for the local jurisdiction in the scenario of a triangular
    transaction.  ex: Triangulation, article 28c,E paragraph 3 of the
    6th EU VAT Directive

    xml:lang
        the language in which the law reference is written.
-->
<!ELEMENT TriangularTransactionLawReference (#PCDATA)>
<!ATTLIST TriangularTransactionLawReference
    xml:lang   %xmlLangCode;    #REQUIRED
>

<!--
    Defines details of one type of tax.

    TaxableAmount
       The taxable amount.

    TaxAmount
       The tax amount.

    TaxLocation
       The tax location.

    Description
       The textual description of the current type of tax.

    TriangularTransactionLawReference
       The law reference for transactions where isTriangularTransaction is True

    purpose
       The purpose of the tax, e.g., tax (tax), custom duty, etc.

    category
       The tax category, Sales tax (sales), Use tax (usage), VAT (vat),
       GST (gst) are defined categories. Other values are permitted.

    percentageRate
       The tax rate in number of percentage.

    isVatRecoverable
       True if the VAT is recoverable.  Default is false.

    taxPointDate
       refers to the date on which VAT becomes due.

    paymentDate
       indicate the date when payment must be made.

    isTriangularTransaction
       True if the transaction is triangular.  Default is false.
-->
<!ELEMENT TaxDetail (TaxableAmount?, TaxAmount, TaxLocation?, Description?,
                     TriangularTransactionLawReference?)>
<!ATTLIST TaxDetail
    purpose                 %string;       #IMPLIED
    category                %string;       #REQUIRED
    percentageRate          %r8;           #IMPLIED
    isVatRecoverable        (yes)          #IMPLIED
    taxPointDate            %datetime.tz;  #IMPLIED
    paymentDate             %datetime.tz;  #IMPLIED
    isTriangularTransaction (yes)          #IMPLIED
>

<!--
    Definition of a cXML Tax item. This represents what a Tax element should
    be in the classic notion of a line on a PO or Invoice. It can also
    represent a per-lineitem tax element depending on where it appears
    (inside of a item ELEMENT or inside of a something like a supplierOrder
    ELEMENT).

    Represents a tax item in the shopping basket. There could be one of these
    for the entire order, or one per lineitem.
-->
<!ELEMENT Tax (Money, Description, TaxDetail*)>

<!-- Item Elements -->
<!--
    The representation of a line item as it needs to be for sending to a
    supplier.

    quantity
        How many items are desired.
    lineNumber
        Position (counting from 1) of this item in an order.  Used to
        maintain a reference between items in create and update OrderRequest
        documents.
    requisitionID
        The buyers system requisition id for this line item. It might be the
        same as orderID, and it might not be included at all.  Must not be
        included if requisitionID is specified in the OrderRequestHeader.
    requestedDeliveryDate
        The date this item was requested for delivery.
    agreementItemNumber 
        The corresponding Item Number of the Item in the Master Agreement if this is 
	a 'release' order item.
-->
<!ELEMENT ItemOut (ItemID, Path?, ItemDetail?, (SupplierID | SupplierList)?, ShipTo?, Shipping?,
                   Tax?, Distribution*, Contact*, Comments?)>
<!ATTLIST ItemOut
    quantity               %r8;      #REQUIRED
    lineNumber             %uint;    #IMPLIED
    requisitionID          %string;  #IMPLIED
    agreementItemNumber	   %string;  #IMPLIED
    requestedDeliveryDate  %date;    #IMPLIED
    isAdHoc                (yes)     #IMPLIED
>

<!--
    The representation of a line item as it needs to be for sending to a
    buyer.

    quantity
        How many items are desired.
    lineNumber
        Position (counting from 1) of this item in an order.  Used to
        maintain a reference between items in create and update OrderRequest
        documents.
-->
<!ELEMENT ItemIn (ItemID, Path?, ItemDetail, SupplierID?, ShipTo?, Shipping?, Tax?)>
<!ATTLIST ItemIn
    quantity   %r8;      #REQUIRED
    lineNumber %uint;    #IMPLIED
>

<!--
    StatusUpdate for Confirmation (type=RequestToPay) request.

    transactionTimestamp
        time when the XMLPay transaction was submitted

    transactionID
        an identifier assisgned to the transaction by the payment processing gateway

    authorizationID
        the authorization code for the transaction provided by the bank

    isFailed
        should have a status code greater than zero.  Zero implies a successful transaction.
-->
<!ELEMENT PaymentStatus (PCard, Total, Shipping?, Tax?, Extrinsic*)>
<!ATTLIST PaymentStatus
    orderID    %string;    #REQUIRED
    transactionTimestamp    %datetime.tz;    #REQUIRED
    type    (Authorization| Settlement| Sale| Credit)    #REQUIRED
    isFailed   (yes)    #IMPLIED
    transactionID    %string;    #IMPLIED
    authorizationID    %string;    #IMPLIED
>

<!--
	Partial amount paid against an InvoiceDetail request. Used in InvoiceStatus.
	If this element exists in an InvoiceStatus element, it should mean that the buyer
	does not pay the full amount as the InvoiceDetail request specified. 
-->
<!ELEMENT PartialAmount (Money)>

<!--
	StatusUpdate for InvoiceDetail request.

	PartialAmount
		The partial amount paid against the InvoiceDetail document.

	Comments
		Comments associated with the status update.

	type
		Type of the invoice status. "reconciled" means that the InvoiceDetail request
		has been received and reconciled. "rejected" means that the InvoiceDetail
		request has been rejected. "paid" means that the InvoiceDetail request has
		been paid.
-->

<!ELEMENT InvoiceStatus (PartialAmount?, Comments*)>
<!ATTLIST InvoiceStatus
	type	(reconciled | rejected | paid)		#REQUIRED
>
	
<!-- OrderRequest* Elements -->
<!--
    Definition of an order.  This is the data that is sent to the supplier
    to have them place an order in their order management system. The new
    world order equivalent of a PO.
-->
<!ELEMENT OrderRequest (OrderRequestHeader, ItemOut+)>

<!--
    Header of an order.  This is the data that is sent to the supplier
    to have them place an order in their order management system. Money
    represents the total amount of this order.

    orderID
        The buyer system orderID for this request. Basically, what the PO
        number is today.

    orderVersion
        The buyer system order version number for this request. Relevant when
        the OrderRequest represents a change order request. The version number
        for the original document should be 1 and should be incremented by 1 for
        each subsequent version (2,3,4...).

    isInternalVersion
        A value of yes indicates that this OrderRequest is a version whose changes from
        the previous version are deemed internal to the buyer system. Relevant when the
        version being sent to the supplier is not the first version.

    orderDate
        The date and time the order request was created.

    type
        The type of the order request. Defaults to "new".

    requisitionID
        The buyers system requisition id for this entire order. It might be
        the same as orderID, and it might not be included at all.  Must not
        be included if requisitionID is specified in any ItemOut elements.

    shipComplete
        Optional preference for "hold until complete" processing.  Defaults
        to shipping when available if not specified.  Future versions of the
        protocol may extend the datatype of this attribute to include
        additional possible values (such as "unlessGreatlyBackOrdered"?).
    orderType
        "release", indicates that this is a Release Order from an existing
	Master Agreement/ Contract. Default is regular.
    agreementID
        Identifies associated agreement corresponding to the Release Order.
	At an implementation level it has to be validated that if the orderType
	is 'release' then the appropriate agreementID is also provided.
    agreementPayloadID
        Optional PayloadID for the corresponding Master Agreement.


    The contained DocumentReference element would appear in a document only
    when the type is "update" or "delete".  In that case, the
    DocumentReference would reference the most recent OrderRequest document
    for the order.  For example when an order is created, updated and then
    deleted, the final document should contain a DocumentReference
    referring to the OrderRequest with type="update".  That document would,
    in turn, refer to the original (type="new") OrderRequest document.
-->
<!ELEMENT OrderRequestHeader (Total, ShipTo?, BillTo, Shipping?, Tax?,
                              Payment?, Contact*, Comments?, Followup?,
                              DocumentReference?, Extrinsic*)>
<!ATTLIST OrderRequestHeader
    orderID    %string;        #REQUIRED
    orderDate  %datetime.tz;   #REQUIRED
    orderType  (release| regular) "regular"
    type       (new | update | delete)  "new"
    orderVersion %number;      #IMPLIED
    isInternalVersion  (yes)   #IMPLIED
    agreementID %string;       #IMPLIED
    agreementPayloadID %string; #IMPLIED
    requisitionID   %string;   #IMPLIED
    shipComplete    (yes)      #IMPLIED
>
<!--
    Definition of a Master Agreement.  This is the electronic document representing the 
    Master Agreement that was created and agreed upon in the Buying organizations.
-->
<!ELEMENT MasterAgreementRequest (MasterAgreementRequestHeader, AgreementItemOut*)>

<!--
   Header of an Agreement.  This is the header level information in the Agreement.
   agreementID
	 The buyer system agreementID for this request.  the Master Agreement Number in Buyer.
   agreementDate
	 The date and time the agreement request was created. 
	 This is different from the effective and expiry date of the agreement.
   agreementType
	 Identifies if this is a Value based agreement or quantity based Agreement.
   requestType
	 The type of the agreement request. Defaults to "new".
   effectiveDate
         Date the Master Agreement is available for ordering/releases.
   expirationDate
         Date the Master Agreement is no longer available.
   parentAgreementPayloadID
	 PayloadID for the corresponding parent document that this agreement is derived from.
   operation: 
	"delete" operation will be used to cancel an existing Master Agreement, the
	 assumption here is that the delete request will be an exact replica of the 
	 original request.
	 "new" operation identifies a new MasterAgreement transaction.
	 "update" operation identified an update to an existing transaction. 
	 the DocumentReference attribute should be used to indicate the Orignal
	 Document information.
   Note: 
	 Use "Contact" element to supply any additional Address or Location information.
-->

<!ELEMENT  MasterAgreementRequestHeader (MaxAmount?, MinAmount?, 
					 MaxReleaseAmount?, MinReleaseAmount?, 
					 Contact*,Comments?, DocumentReference?,  Extrinsic*)> 
<!ATTLIST MasterAgreementRequestHeader
    agreementID    %string;		   #REQUIRED
    agreementDate  %datetime.tz;	   #REQUIRED
    type	   (value | quantity)	   "value"
    effectiveDate  %datetime.tz;	   #REQUIRED
    expirationDate %datetime.tz;	   #REQUIRED
    parentAgreementPayloadID %string;      #IMPLIED
    operation      (new | update | delete) "new"
>

<!--
    The representation of a  agreement line item as it needs to be for sending to a
    supplier.
    maxQuantity 
          maximum quantity for this particular lineItem
    minQuantity 
          minimum quantity for this particular lineItem
    maxReleaseQuantity 
          maximum quantity per release for this particular lineItem
    minReleaseQuantity 
          minimum quantity per release for this particular lineItem

    Note :
	  The #lineNumber attribute in the <ItemOut> will be used to specify the corresponding 
	  lineNumber on the Master Agreement in the Procurement Application.
	  At an implementation, level checks should be made to validate this.
    Note :
	  The quantity attribute in the ItemOut tag should be set to one and ignored at 
	  the Mater Agreement implementation processing stage. 
    Note :
	  The MaxReleaseAmount/Quantity and MinReleaseAmount/Quantity at an item level i
	  indicate the ItemLevel amounts and quantities per release.
-->
<!ELEMENT AgreementItemOut (MaxAmount?, MinAmount?, MaxReleaseAmount?, MinReleaseAmount?, ItemOut)>
<!ATTLIST AgreementItemOut
   maxQuantity		%r8;      #IMPLIED
   minQuantity		%r8;      #IMPLIED
   maxReleaseQuantity	%r8;      #IMPLIED
   minReleaseQuantity	%r8;      #IMPLIED
>

<!--
    The maximum amount  for something.
-->
<!ELEMENT MaxAmount (Money)>

<!--
    The minimum amount  for something.
-->
<!ELEMENT MinAmount (Money)>

<!--
    The contractual maximum amount per Release of this Master Agreement.
-->
<!ELEMENT MaxReleaseAmount (Money)>

<!--
 The contractual minimum amount per Release of this Master Agreement
-->
<!ELEMENT MinReleaseAmount (Money)>


<!-- Followup

     Location to which future StatusUpdateRequest documents should be
     posted.  In general, this is the input location for any later
     documents which reference the current OrderRequest document.
-->
<!ELEMENT Followup (URL)>

<!-- PunchOut* Elements -->
<!--
    Definition of a PunchOut Setup Request.  This is the data that is sent
    to the external system that the procurement application is going to
    extract catalog data from.

    The BrowserFormPost element contains the URL we would like the browser
    re-directed to when the PunchOut shopping experience is finished (where
    the PunchOutOrder message should be returned).
-->
<!ELEMENT PunchOutSetupRequest (BuyerCookie, Extrinsic*, BrowserFormPost?,
                                Contact*, SupplierSetup?, ShipTo?,
                                SelectedItem?, ItemOut*)>
<!ATTLIST PunchOutSetupRequest
    operation  (create | inspect | edit | source)  #REQUIRED
>

<!ELEMENT BuyerCookie ANY> <!-- any valid XML data -->

<!ELEMENT SelectedItem (ItemID)>
<!ELEMENT SupplierSetup (URL)>

<!ELEMENT PunchOutSetupResponse (StartPage)>

<!--
    Definition of a PunchOut Order Message.  This is the data that is sent
    back to the procurement application from the external system that the
    PunchOut Request was targeted at.
-->
<!ELEMENT PunchOutOrderMessage (BuyerCookie, PunchOutOrderMessageHeader,
                                ItemIn*)>

<!--
     Header of a PunchOut Order Request.  This is the data that is sent from
     the supplier to transfer the supplier acquired shopping basket back to
     the buyer system.

     operationAllowed
          Highest operation allowed on the PunchOut shopping basket.
          "create" allows only later OrderRequest operations on these items.
          "inspect" adds a PunchOutSetupRequest with operation="inspect".
          And, "edit" allows operation="edit" in that later Setup request.

     quoteStatus 
          "pending"  - Identifies that the transaction is still pending
	  "final" - Identifies that the transaction is complete
-->
<!ELEMENT PunchOutOrderMessageHeader (SourcingStatus?, Total, ShipTo?, Shipping?, Tax?)>
<!ATTLIST PunchOutOrderMessageHeader
    operationAllowed  (create | inspect | edit)  #REQUIRED
    quoteStatus (pending|final) "final"
>

<!-- ====
    Other small Request elements.
==== -->

<!--
    Request to update the status of an earlier transaction.
-->
<!ENTITY % cxml.statuses  "(PaymentStatus |
			    SourcingStatus | InvoiceStatus)">
<!ELEMENT StatusUpdateRequest  (DocumentReference, Status, (%cxml.statuses;)?)>

<!--
    Request to forward a cXML document to another party.  This Request
    occurs in multiple DTD files and is used depending on where (in which
    DTD) the forwarded message resides.
-->
<!ELEMENT CopyRequest (cXML)>
<!--
    Status for a pre-existing sourcing transaction. The textual content indicates
    the display information. "action" attribute defines the context of this message
    based on the value.

    approve : Approve the pending transaction
    deny : deny pending transaction
    cancel : cancel any preexisting transaction.

-->
<!ELEMENT SourcingStatus (#PCDATA)>
<!ATTLIST SourcingStatus
action    (approve | cancel | deny )  #IMPLIED
xml:lang %xmlLangCode; #REQUIRED>
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/Modules/Reference.mod#1 $
-->

<!--
    For better definitions of these Elements/Entities, refer to the cXML
    User's Guide and related documents.
-->

<!--
    The OrderReference element provides a clear reference to a prior
    OrderRequest document.  While the contained DocumentReference provides
    an unambiguous reference, the additional attributes of the
    OrderReference may allow the ConfirmationRequest and ShipNoticeRequest
    to be viewed independently.

    orderID
        The buyer system orderID for this request. Basically, what the PO
        number is today.  If present, must be copied directly from the
        referenced OrderRequest document's OrderRequestHeader.
    orderDate
        The date and time the order request was created.  If present, must
        be copied directly from the referenced OrderRequest document's
        OrderRequestHeader.
-->
<!ELEMENT OrderReference (DocumentReference)>
<!ATTLIST OrderReference
    orderID              %string;              #IMPLIED
    orderDate            %datetime.tz;         #IMPLIED
>

<!--
    Identifies the carrier who will transport a shipment.

    domain
        Domain in which this value has meaning.  Recognized domains
        include:
        companyName - The legal name for this company.  In some cases, this
            could also be provided in a Contact element with role
            "carrierCorporate".  That option should be reserved for cases
            in which additional detail about the carrier appears in this
            element.
        SCAC - Standard Carrier Alpha Code (see
            http://users.erols.com/nmfta/Codes.htm)
        IATA - International Air Transport Association (see
            http://www.iata.org)
        AAR  - Association of American Railroads (see http://www.aar.org/)
        UIC  - International Union of Railways (see
            http://www.uic.asso.fr/)
        EAN  - European Article Numbering (see http://www.ean-ucc.org/)
        DUNS - D&B's Data Universal Numbering System (see
            http://www.dnb.com/dnbhome.htm)
-->
<!ELEMENT CarrierIdentifier (#PCDATA)>         <!-- string -->
<!ATTLIST CarrierIdentifier
    domain               %string;              #REQUIRED
>

<!--
    Identifier that appears on a shipment and through which additional
    detail about the shipment may be retrieved.  Defined by the carrier.
    Has meaning in the domain described by the CarrierIdentifier values.
    Therefore, CarrierIdentifier and ShipmentIdentifier should normally 
    be used together.

    Conceptually, this is a tracking number.  Different carriers have
    different names for shipment identifiers.  Some call it a way bill
    number, others call it a pro number, and still others call it a bill of
    lading.  They all represent tracking numbers.
-->
<!ELEMENT ShipmentIdentifier (#PCDATA)>        <!-- string -->

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

    $Id: //ariba/cxml/Modules/Fulfill.mod#2 $
-->

<!-- ====
    Allow this module to be built separately from any other DTD file.
==== -->

<!ENTITY % cxml.requests "(ConfirmationRequest |
                           ShipNoticeRequest |
                           CopyRequest)"
>
<!-- Unused! -->
<!ENTITY % cxml.responses "(PunchOutSetupResponse)">
<!-- Unused! -->
<!ENTITY % cxml.messages "(PunchOutOrderMessage)">

<!-- ====
    Common to both of the documents listed below.
==== -->

<!--
    Either or both a textual description and codes about a hazard inherent
    in an item or for the overall order or shipment.  The overall hazards
    may be due either to identical hazards for all items or hazards
    inherent in shipping various products together.

    The contained Description element list (if provided) should include
    detailed handling requirements.  Elements in this list may appear in
    any order.  A description locale (Description@xml:lang attribute value)
    must not appear more than once in a Hazard element.  When more than one
    Description element is present, all must contain translations of a
    common description.

    Classification elements may appear in any order.  A classification
    domain (Classification@domain attribute value) must not appear more
    than once in a Hazard element.

    All listed Classification elements and the Description (if provided)
    must relate to a single hazard.  Additional hazards must use separate
    Hazard elements.

    The following Classification domains are expected in this context:
        UNDG - United Nations Dangerous Goods
        IMDG - International Marine Organization Dangerous Goods
        NAHG - North American Hazardous Goods
-->
<!ELEMENT Hazard ((Description+, Classification*) | Classification+)>

<!-- ====
    Confirmation* transaction forwards confirmation data in the Request.
    No specific Response document is required for this transaction.
    Servers must respond to a ConfirmationRequest with a generic Response
    document.
==== -->

<!--
    Request to add confirmation information to the data known about an
    order at the receiving server.

    While multiple confirmations may be sent for one order, each
    confirmation must mention a line item once.  And, a line item must not
    be mentioned in more than one confirmation.  Multiple confirmations are
    allowed (and sensible) only when each has type="allDetail" or
    type="detail".  Only one (original) confirmation per order of
    type="accept", type="except" or type="reject" is allowed.  When a
    confirmation with one of these types arrives, the receiving system must
    discard any and all previous confirmations for the order.

    ConfirmationItem elements may appear in any order within the
    ConfirmationRequest.  Of course, an easily-readable order such as by
    increasing lineNumber value is preferred.  Again, no line item
    (Confirmation@lineNumber attribute value) may appear more than once
    within a ConfirmationRequest element.
-->
<!ELEMENT ConfirmationRequest
    (ConfirmationHeader, OrderReference, ConfirmationItem*)>

<!--
    Information about this confirmation that's common to all contained
    items.

    The contained DocumentReference element may appear in a document only
    when the operation is "update".  In that case, the DocumentReference is
    required and it must reference the most recent ConfirmationRequest
    document for this particular confirmation (usually also indicated by a
    common confirmID).  For example when a confirmation is created, updated
    and then updated again, the final document must contain a
    DocumentReference referring to the previous ConfirmationRequest with
    operation="update".  That document must, in turn, refer to the original
    (operation="new") ConfirmationRequest document.

    Tax and Shipping amounts may be updated (included in the confirmation
    with new values) without corresponding line item information
    (additional information in the ConfirmationItem list).  Total should
    not be included with a different value from the OrderRequest document
    unless a ConfirmationItem describes a new UnitPrice or quantity.  It is
    not necessary to copy this information from the OrderRequest document:
    Total, Tax and Shipping should not be included if they match those
    amounts in the original order.

    Contact roles may usefully include: technicalSupport, customerService,
    sales, shipFrom (starting point for shipments related to this order),
    shipTo (echoing the ShipTo element from the OrderRequest document),
    payTo (where payment for this order should be sent), billTo (echoing
    the BillTo element from the OrderRequest document), buyerCorporate
    (details the supplier has about the buying organization) and
    supplierCorporate.  It is not necessary to copy this information from
    the OrderRequest document: The Contact element should be used primarily
    to add information to that known about an order or to describe the
    sender of this particular confirmation.

    Elements in the Contact list may appear in any order.  A contact role
    (Contact@role attribute value) must not appear more than once within a
    ConfirmationHeader element.

    Elements in the Hazard list may appear in any order.  The same hazard
    should not be listed more than once in a ConfirmationHeader.  Each
    hazard listed at this level (in a ConfirmationHeader element) should
    apply to the entire order or all items mentioned in this confirmation.
    A ConfirmationRequest which updates the status of a single line item
    should not include Hazard elements in the ConfirmationItem element.

    The Comments element list may contain additional information about the
    status of the overall order (or the portion described in this
    confirmation) such as payment terms, additional detail on shipping
    terms and clarifications of the status.  For the last type of
    information, terms such as "backordered", "shipped" and "invalid" may
    be sensible.  All such data must be intended for human use.  The text
    in this list should describe this particular confirmation and not
    repeat Comments appearing in the OrderRequest.

    Elements in the Comments list may appear in any order.  The xml:lang
    attribute may have the same value in multiple Comments elements in the
    list.  The set of Comments with a particular xml:lang value should
    contain similar content to that for any other xml:lang value present in
    the list.

    On the other hand, the Extrinsic element list may be used to insert
    additional data about the order for application consumption.  These
    elements may include pre-defined keywords and values affecting workflow
    in the receiving system.

    Elements in the Extrinsic list may appear in any order.  An extrinsic
    type (Extrinsic@name attribute value) must not appear more than once
    within a ConfirmationHeader element.  A type may not be mentioned both
    in this list and in a particular ConfirmationStatus element.  (The
    ConfirmationHeader must not contain a default extrinsic value
    overridden at the lower level.)

    confirmID
        An (optional) identifier for this particular confirmation assigned
        by the supplier.  A user-visible and secondary (to the payloadID
        attribute of the cXML element) identifier for this document.  This
        value does not vary as a particular confirmation is updated.  That
        is, operation="update" documents describing the status of the same
        items in the same order would share a confirmID with the original
        operation="new" ConfirmationRequest.

        When the confirmID does not appear in an operation="new"
        ConfirmationRequest, it must not appear in a corresponding
        operation="update" document.  Links between these documents must be
        deduced using the DocumentReference element contained in the
        update's ConfirmationHeader and the payloadID attribute of the
        original or previous update.
    operation
        The (optional) operational mode of the confirmation document.
        Defaults to "new".

        An "update" confirmation allows a supplier to correct an error in a
        confirmation or to add additional information learned later.  In
        either case, an "update" document must be complete: All data from
        the original confirmation or a previous update should be discarded
        by the recipient.  A ConfirmationRequest document does not provide
        default data for a subsequent operation="update" document.  (This
        applies in particular to Hazard and Extrinsic elements, which
        should appear at either the header or item levels but not both.)

        The "completeness" requirement allows the information contained in
        a ConfirmationRequest to expand.  No restrictions are placed on
        including additional items that have not yet been referenced in a
        ConfirmationRequest in a operation="update" ConfirmationRequest.
        However, added items must not have been mentioned in another
        ConfirmationRequest unless all items from that (other) confirmation
        are now described in the consolidated document.  This protocol
        supports neither splitting confirmations (sending an
        operation="update" ConfirmationRequest document describing a subset
        of the items in an earlier version) nor partial consolidations of
        confirmations (sending an operation="update" ConfirmationRequest
        document that contains a subset of the information from another
        confirmation).

        An operation="update" ConfirmationRequest must contain the same
        confirmID (if any) as the previous version of the confirmation.
        When included, this attribute provides an unambiguous and direct
        connection between all versions of the confirmation.

        An operation="update" ConfirmationRequest must also include a
        DocumentReference element in the ConfirmationHeader.  (See above
        for more information on this element.)  This effectively sequences
        multiple versions of a confirmation and may provide the only link
        between those versions.  (See above under confirmID for more on the
        implications of leaving out that attribute.)  Other confirmations
        discarded through consolidations as described above are not
        explicitly referenced by the new, larger ConfirmationRequest
        document.

        A confirmation may not be deleted; the protocol does not include an
        operation="delete" option for this request.  Suppliers must replace
        incorrect or invalid confirmations with correct information.  A
        type="unknown" ConfirmationStatus will reset such information to
        its original state.  This covers the case of an error in accepting
        or rejecting an item that has not been researched.
    type
        The type of confirmation:
        accept
            The entire order is accepted as described in the referenced
            OrderRequest document.

            A document of this type may contain ConfirmationItem elements.
            If ConfirmationItem elements are present in the
            ConfirmationRequest document, they must contain only
            ConfirmationStatus elements of type="accept".
        allDetail
            This confirmation updates only those line items described in
            the following ConfirmationItem elements.  Line items not
            mentioned specifically in this document retain their current
            status.  Unlike the "detail" type (below), a confirmation of
            this type includes all information known by the supplier,
            whether or not it differs from the data provided in the
            original OrderRequest document.

            This type is provided for compatibility with current EDI and
            order entry tools (which commonly send the buyer a snapshot of
            an order in the supplier's systems).  Due to the reconciliation
            issues caused by confirmations of this type, it is recommended
            that use of this type be considered a "bridge" strategy
            suitable only for the short term.

            A document of this type must contain ConfirmationItem elements.
            The contained ConfirmationStatus elements must have types
            "allDetail", "reject" or "unknown".  "accept" , "detail" 
            or "backordered". status types are not allowed because they 
            conflict with the requirements of this document type.
        detail
            This confirmation updates only those line items described in
            the following ConfirmationItem elements.  Line items not
            mentioned specifically in this document retain their current
            states.  A confirmation of this type should include only
            information which differs from that in the original
            OrderRequest document.

            Later ConfirmationRequest documents that restore information
            provided in the OrderRequest should not include the variations
            described in an earlier ConfirmationRequest.  For example, the
            Tax element may appear in a ConfirmationStatus of one
            ConfirmationRequest and not in an update to that confirmation.
            This signifies that the original OrderRequest actually
            contained the correct charge.

            A document of this type must contain ConfirmationItem elements.
            The contained ConfirmationStatus elements may have any type
            except "allDetail".

        backordered
            The entire order is backordered.

            A document of this type may contain ConfirmationItem elements.
            If ConfirmationItem elements are present in the
            ConfirmationRequest document, they must contain only
            ConfirmationStatus elements of type="backordered".

        except
            The entire order is accepted as described in the referenced
            OrderRequest document with exceptions listed in the following
            ConfirmationItem elements.  Line items not mentioned
            specifically in this document are accepted without change.

            A document of this type must contain ConfirmationItem elements.
            The contained ConfirmationStatus elements may have any type
            except "allDetail".
        reject
            The entire order is rejected.  No further (line item) detail is
            provided beyond the reason described in the Comments element.

            A document of this type must not contain ConfirmationItem
            elements.
        requestToPay
            This type of confirmation is for the supplier to request the
            initiation of payment transactions for either the whole
            order or some line items.

            If the request contains no ConfirmationItem elements, the intent
            will be to initiate payment transaction on the total amount of
            all line items in the order, except those being rejected.

            If the request contains ConfirmationItem elements, payment
            transaction will be initiated against the specified items and
            quantities.

            A ConfirmationItem in this type of request does not have to
            describe the complete line item. It should only contain
            "requestToPay" ConfirmationStatus elements for new payment
            transactions.
    noticeDate
        The date and time this confirmation was created.
    invoiceID
        An optional supplier-generated identifier for an Invoice associated
        with the items described in this confirmation.  Identical to the
        Invoice Number which appears at the top of a physical Invoice.
    incoTerms
        Optional shipping terms as defined by the International Chamber of
        Commerce.  These terms inform the buyer which portion of the
        shipping charges are their responsibility.  Allowed values include:
            cfr - Cost and freight
            cif - Cost, insurance and freight
            cip - Carriage and insurance paid to
            cpt - Carriage paid to
            daf - Delivered at frontier
            ddp - Delivered duty paid
            ddu - Delivered duty unpaid
            deq - Delivered ex quay (duty paid)
            des - Delivered ex ship
            exw - Ex works
            fas - Free alongside ship
            fca - Free carrier
            fob - Free on board vessel
-->
<!ELEMENT ConfirmationHeader (DocumentReference?, Total?, Shipping?,
                              Tax?, Contact*, Hazard*, Comments*,
                              Extrinsic*)>
<!ATTLIST ConfirmationHeader
    confirmID            %string;                        #IMPLIED
    operation            (new | update)                  "new"
    type (accept | allDetail | detail | backordered | except | reject | requestToPay)
                                                         #REQUIRED
    noticeDate           %datetime.tz;                   #REQUIRED
    invoiceID            %string;                        #IMPLIED
    incoTerms (cfr | cif | cip | cpt | daf | ddp | ddu | deq | des | exw |
               fas | fca | fob)                          #IMPLIED
>

<!--
    Information about a specific line item.  Must completely describe the
    status of the referenced line item.  For example, two
    ConfirmationRequest documents may be necessary to update the status of
    an entire order.  However, a particular item must be mentioned in only
    one of these documents.

    A particular line item from an order must not be mentioned in more than
    one ConfirmationItem element.

    Any Contact elements provided at this level describe contacts specific
    to this item.  The ConfirmationHeader description mentions roles
    appropriate at this level as well.  A particular Contact role must not
    appear in both the ConfirmationItem and ConfirmationHeader elements.

    Elements in the Contact list may appear in any order.  A contact role
    (Contact@role attribute value) must not appear more than once within a
    ConfirmationItem element.

    Elements in the Hazard list may appear in any order.  The same hazard
    should not be listed more than once in a ConfirmationItem.  Each hazard
    listed at this level (in a ConfirmationItem element) must apply to the
    this specific line item.  A ConfirmationRequest which updates the
    status of a single line item should not include Hazard elements in the
    ConfirmationItem element.

    The list of ConfirmationStatus elements may appear in any order.
    However, the described quantities must sum to the quantity of the
    containing ConfirmationItem element (after any conversions required by
    use of different UnitOfMeasure scales at each level).  This ensures the
    status of a particular line item is completely described in a
    ConfirmationRequest document.

    quantity
        Number of this line item which was ordered.  Expressed in the units
        given in the UnitOfMeasure element.  Copied directly from the
        corresponding line item (ItemOut) in the document referenced in the
        OrderReference element.
    lineNumber
        Position (counting from 1) of this item in an order.  Copied
        directly from the corresponding line item (ItemOut) in the document
        referenced in the sibling OrderReference element.
-->
<!ELEMENT ConfirmationItem
    (UnitOfMeasure, Contact*, Hazard*, ConfirmationStatus+)>
<!ATTLIST ConfirmationItem
    quantity             %r8;                  #REQUIRED
    lineNumber           %uint;                #REQUIRED
>

<!--
    Confirmation status of a specific line item or portion thereof.
    Quantities at this level must sum to that in the containing
    ConfirmationItem.  Documents should use a consistent UnitOfMeasure in
    ConfirmationItem and contained ConfirmationStatus elements.  A
    substitution (replacement item) may use a different UnitOfMeasure in
    the ItemDetail contained within the ItemIn element.

    In the normal case (for simple acceptance or rejection of this item),
    the ConfirmationStatus element would contain only a UnitOfMeasure
    element and the quantity and type attributes.  ItemIn appears in this
    element if and only if the supplier is recommending a substitution or
    the type is "allDetail".  In that case, the quantity of the ItemIn
    element must match that of the containing ConfirmationStatus unless the
    UnitOfMeasure is different.  ItemDetail must appear inside ItemIn
    whenever ItemIn appears in this context.  That is, an ItemIn element in
    a ConfirmationStatus element must contain an ItemDetail element.

    UnitPrice, Tax and Shipping amounts may be updated (included in the
    ConfirmationStatus element with new values) without a complete part
    substitution.  It is not necessary to copy this information from the
    OrderRequest document: UnitPrice, Tax and Shipping should not be
    included if they match that in the original ItemOut element.  The
    addition of tax or shipping amounts not mentioned in the original order
    may appear when the type is "accept", "allDetail" or "detail".  The
    "accept" type should be used if these additions are the only changes
    from the order.  The "detail" type implies a substitution (presence of
    the ItemIn element), price change (presence of the UnitPrice element)
    or delayed shipment (presence of the deliveryDate attribute).
    Unfortunately, the "allDetail" type requires reconciliation software to
    determine what has changed since the original order.

    The Comments element list may contain additional information about the
    status of this portion of the item such clarifications of the type
    attribute.  Terms such as "backordered", "shipped" and "invalid" may be
    sensible.  All such data must be intended for human use.

    Elements in the Comments list may appear in any order.  The xml:lang
    attribute may have the same value in multiple Comments elements in the
    list.  The set of Comments with a particular xml:lang value should
    contain similar content to that for any other xml:lang value present in
    the list.

    On the other hand, the Extrinsic element list may be used to insert
    additional data about this particular item portion for application
    consumption.  These elements may include pre-defined keywords and
    values affecting workflow in the receiving system.

    Elements in the Extrinsic list may appear in any order.  An extrinsic
    type (Extrinsic@name attribute value) must not appear more than once
    within a ConfirmationStatus element.  A type may not be mentioned both
    in this list and in the overall ConfirmationHeader element.  (The
    ConfirmationHeader must not contain a default extrinsic value
    overridden at this lower level.)

    quantity
        Number of this line item which has this status.  Expressed in the
        units given in the UnitOfMeasure element.
    type
        The status of this particular portion of the order:
        accept
            This portion of the line item is accepted as described in the
            referenced ItemOut element.

            This type is allowed in documents with overall
            (ConfirmationHeader) types "accept", "detail" or "except".
        allDetail
            This portion of the line item is accepted as detailed in the
            contents of this ConfirmationStatus element.  These contents
            completely describe what will be shipped.  Unlike the "detail"
            type (below), a confirmation of this type includes all
            information known by the supplier, whether or not it differs
            from the data provided in the original OrderRequest document.

            This type is provided for compatibility with current EDI and
            order entry tools (which commonly send the buyer a snapshot of
            an order in the supplier's systems).  Due to the reconciliation
            issues caused by confirmations of this type, it is recommended
            that use of this type be considered a "bridge" strategy
            suitable only for the short term.

            This type is allowed only in documents with overall
            (ConfirmationHeader) type "allDetail".
        detail
            This portion of the line item is accepted with the changes
            detailed in the contents of this ConfirmationStatus element.
            At least one of the UnitPrice, Shipping, Tax or ItemIn elements
            or the deliveryDate attribute must be present.

            This type is allowed in documents with overall
            (ConfirmationHeader) types "detail" or "except".

        backordered
            This portion of the line item is backordered.

            This type is allowed in documents with overall
            (ConfirmationHeader) types "backordered", "detail" ,"except",
            and "allDetail". "shipmentDate" and "deliveryDate" attributes for 
            this type of ConfirmationStatus are optional. The rest of elements
            for this type of ConfirmationStatus are ignored.

        reject
            This portion of the line item is rejected.

            This type is allowed in documents with overall
            (ConfirmationHeader) types "allDetail", "detail" or "except".
        requestToPay
            A requestToPay is being asked about this portion of the line
            item. Request-to-pay will initiate a request to the financial
            institution to begin the settlement process of the portion of
            the line item.

            This type is allowed in documents with overall request
            (ConfirmationHeader) type "requestToPay".
        unknown
            The status of this portion of the line item is not known at
            the time of this confirmation.  This line item status may
            provide a "placeholder" while the supplier does further
            research.  Update confirmations may also reset the status of a
            line item portion to "unknown" when an earlier confirmation
            (incorrectly) accepted or rejected that portion.

            This type is allowed in documents with overall
            (ConfirmationHeader) types "allDetail", "detail" or "except".
    shipmentDate
        The date and time this shipment is expected to leave the supplier.
        A ConfirmationStatus element should include this information if the
        type is "accept", "allDetail" or "detail".
    deliveryDate
        The date and time this shipment is expected to arrive.  Should not
        be included if the value matches that of the requestedDeliveryDate
        attribute (if any) in the corresponding OrderRequest document.
        Otherwise, a ConfirmationStatus element should include this
        information if its type is "accept", "allDetail" or "detail".
-->
<!ELEMENT ConfirmationStatus (UnitOfMeasure, (ItemIn | (UnitPrice?, Tax?,
                              Shipping?)), Comments*, Extrinsic*)>
<!ATTLIST ConfirmationStatus
    quantity             %r8;                             #REQUIRED
    type (accept | allDetail | detail | backordered | reject | unknown | requestToPay)
                                                          #REQUIRED
    shipmentDate         %datetime.tz;                    #IMPLIED
    deliveryDate         %datetime.tz;                    #IMPLIED
>

<!-- ====
    ShipNotice* transaction forwards ship notice data in the Request.  No
    specific Response document is required for this transaction.  Servers
    must respond to a ShipNoticeRequest with a generic Response document.
==== -->

<!--
    Request to add shipment information to the data known about an order at
    the receiving server.

    Shipments with multiple responsible carriers may be described in one of
    two ways:
    1. A single carrier (or third-party logistics provider) creates a
       tracking identifier that may be used to retrieve information about
       the entire trip.  Suppliers send such information in a single
       ShipControl element.  Optionally, they may use Route elements to
       describe lower-level carriers.
    2. Separate tracking numbers are required for each segment.  Suppliers
       send such information with one ShipControl element per segment.

    ShipControl elements must appear in the order the shipment will travel.
    The first such element must not have an explicit starting date (the
    ShipControl@startDate attribute must not be present) and that carrier's
    control must begin at the shipment's origination time
    (ShipNoticeHeader@shipmentDate attribute value).  All later ShipControl
    elements must have increasing (later) starting dates
    (ShipControl@startDate attribute value).

    ShipNoticePortion elements may appear in any order.  A particular order
    (ShipNoticePortion/OrderReference/DocumentReference@payloadID attribute
    value) must not appear more than once in a ShipNoticeRequest element.

    Note: Many elements and attributes in the ShipNoticeRequest and
    ShipNoticeHeader elements are optional only for the operation="delete"
    case.  For other operations, one or more ShipControl and
    ShipNoticePortion elements must appear in a ShipNoticeRequest element.
-->
<!ELEMENT ShipNoticeRequest
    (ShipNoticeHeader, ShipControl*, ShipNoticePortion*)>

<!--
    Information about this ship notice that's common to all contained
    items.

    One or more ServiceLevel elements must appear in all ShipNoticeRequest
    documents except when operation="delete" is specified.  Each
    ServiceLevel must contain a single string corresponding to the level of
    service (such as "overnight") provided by the carrier for this
    shipment.  When multiple ServiceLevel elements appear, all must
    describe the same level of service in different languages or locales.
    (No two ServiceLevel elements may have the same xml:lang attribute.)
    Elements in such a list may appear in any order.

    The contained DocumentReference element may appear in a document only
    when the operation is "update" or "delete".  In that case, the
    DocumentReference is required and it must reference the most recent
    ShipNoticeRequest document for this particular ship notice (also
    indicated by a common shipmentID).  For example when a ship notice is
    created, updated and then updated again, the final document must
    contain a DocumentReference referring to the previous ShipNoticeRequest
    with operation="update".  That document must, in turn, refer to the
    original (operation="new") ShipNoticeRequest document.

    Contact roles may usefully include: technicalSupport, customerService,
    sales, shipFrom (starting point for this shipment), shipTo (should echo
    the ShipTo element from the OrderRequest documents), buyerCorporate
    (details the supplier has about the buying organization) and
    supplierCorporate.  It is not generally necessary to copy information
    from the various OrderRequest documents: The Contact element should be
    used primarily to add information to that known about an order.

    Elements in the Contact list may appear in any order.  A contact role
    (Contact@role attribute value) must not appear more than once within a
    ShipNoticeHeader element.

    Elements in the Hazard list may appear in any order.  The same hazard
    should not be listed more than once in a ShipNoticeHeader.  Each hazard
    listed at this level (in a ShipNoticeHeader element) should apply to
    the entire shipment or all items contained in this shipment.  A
    ShipNoticeRequest for a single line item should not include Hazard
    elements in the ShipNoticeItem element.

    The Comments element list may contain additional information about the
    shipment.  In this context (the ShipNoticeHeader), that information
    must be common to all contained items and routes.  All such data must
    be intended for human use.

    Elements in the Comments list may appear in any order.  The xml:lang
    attribute may have the same value in multiple Comments elements in the
    list.  The set of Comments with a particular xml:lang value should
    contain similar content to that for any other xml:lang value present in
    the list.

    On the other hand, the Extrinsic element list may be used to insert
    additional data about the shipment for application consumption.  These
    elements may include pre-defined keywords and values affecting workflow
    in the receiving system.

    Elements in the Extrinsic list may appear in any order.  An extrinsic
    type (Extrinsic@name attribute value) must not appear more than once
    within a ShipNoticeHeader element.  A type may not be mentioned both in
    this list and in a particular ShipControl or ShipNoticePortion element.
    (The ShipNoticeHeader must not contain a default extrinsic value
    overridden at either lower level.)

    shipmentID
        An identifier for this particular shipment assigned by the
        supplier.  A user-visible and secondary (to the payloadID attribute
        of the cXML element) identifier for this document.  This value does
        not vary as a particular ship notice is updated.  That is,
        operation="update" or operation="delete" documents describing the
        same shipment must share a shipmentID with the original
        operation="new" ShipNoticeRequest.
    operation
        The (optional) operational mode of ship notice document.  Defaults
        to "new".

        An "update" ship notice allows a supplier to correct an error in a
        ship notice or to add additional information learned later.  In
        either case, an "update" document must be complete: All data from
        the original should be discarded by the recipient.

        A "delete" ship notice removes the changes described in the
        previous ShipNoticeRequest (either operation="new" or a previous
        update) from the state of the shipment.  This operation should be
        used only when the supplier discards a planned shipment or
        incorrectly sends a ShipNoticeRequest about a shipment that will
        not take place.

        An "update" or "delete" ship notice must have the same shipmentID
        as the previous version of the notice.  This provides an
        unambiguous and direct connection between all versions of the ship
        notice.

        If the operation is not "new" (explicitly or by default), the
        ShipNoticeRequest must also include a DocumentReference element in
        the ShipNoticeHeader.  (See above for more information on this
        element.)  This effectively sequences multiple versions of a ship
        notice.
    noticeDate
        The date and time this ship notice was created.
    shipmentDate
        The date and time this shipment left the supplier.  This attribute
        must appear in all ShipNoticeRequest documents except when
        operation="delete" is specified.
    deliveryDate
        The date and time this shipment is expected to arrive.  While this
        value may default to the requestedDeliveryDate of a single order,
        that attribute is optional in an OrderRequest document and the
        ShipNoticeRequest may refer to multiple OrderRequest documents.
        This attribute must appear in all ShipNoticeRequest documents
        except when operation="delete" is specified.
-->
<!ELEMENT ShipNoticeHeader (ServiceLevel*, DocumentReference?, Contact*,
                            Hazard*, Comments*, Extrinsic*)>
<!ATTLIST ShipNoticeHeader
    shipmentID           %string;              #REQUIRED
    operation          (new | update | delete) "new"
    noticeDate           %datetime.tz;         #REQUIRED
    shipmentDate         %datetime.tz;         #IMPLIED
    deliveryDate         %datetime.tz;         #IMPLIED
>

<!--
    One language-specific string for the service level code.  Each
    ServiceLevel must contain a string (in the specified language)
    corresponding to the level of service (such as "overnight") provided by
    the carrier for this shipment.

    xml:lang
        The language or locale in which the ServiceLevel content (the name
        of the service level) is written.
-->
<!ELEMENT ServiceLevel (#PCDATA)>              <!-- string -->
<!ATTLIST ServiceLevel
   xml:lang              %xmlLangCode;         #REQUIRED
>

<!--
    Carrier responsible for some portion of the shipment.  The shipment
    will be tracked using the identifiers provided at this level.  Those
    identifiers should be valid from the startDate of one ShipControl
    element or the shipment's shipmentDate until the startDate of the next.

    The CarrierIdentifier list may include multiple identifiers for the
    same carrier.  Elements in this list may appear in any order.  A
    particular identification domain (CarrierIdentifier@domain attribute
    value) must not appear more than once in a ShipControl element.  The
    identification provided by all elements of the CarrierIdentifier list
    must correspond to the same company.

    If present, Route elements must be in the order the shipment will
    travel.

    The only Contact roles likely to be sensible in this element are
    "carrierCorporate" (details the contact information the supplier has
    about the carrier organization) and "shipFrom".  A Contact element with
    role "shipFrom" must appear in all ShipControl elements after the
    first.  This role must not appear in the first ShipControl element
    since it would duplicate that role in the overall ShipNoticeHeader
    element.  Since a Contact with role "shipTo" would always duplicate
    information in the following ShipControl element or that role in the
    ShipNoticeHeader, such a Contact must not appear in this element.  In
    essence, control passes from one carrier to another at a particular
    location and (estimated) time.

    Elements in the Contact list may appear in any order.  A contact role
    (Contact@role attribute value) must not appear more than once within a
    ShipControl element.

    The Comments element list may contain additional information about the
    shipment while under the control of this carrier.  In this context (the
    ShipControl element), that information must be common to all contained
    routes or make it clear which Route is affected.  All such data must be
    intended for human use.

    Elements in the Comments list may appear in any order.  The xml:lang
    attribute may have the same value in multiple Comments elements in the
    list.  The set of Comments with a particular xml:lang value should
    contain similar content to that for any other xml:lang value present in
    the list.

    On the other hand, the Extrinsic element list may be used to insert
    additional data about this carrier or their period of responsibility
    for application consumption.  These elements may include pre-defined
    keywords and values affecting workflow in the receiving system.

    Elements in the Extrinsic list may appear in any order.  An extrinsic
    type (Extrinsic@name attribute value) must not appear more than once
    within a ShipControl element.  A type may not be mentioned both in this
    list and in the overall ShipNoticeHeader element.  (The
    ShipNoticeHeader must not contain a default extrinsic value overridden
    at this lower level.)

    startDate
        The date and time this shipment started this part of the route.
        Required for all ShipControl elements after the first.  This
        attribute must not appear in the first ShipControl element since it
        would duplicate the ShipNoticeHeader's shipmentDate attribute.
-->
<!ELEMENT ShipControl (CarrierIdentifier+, ShipmentIdentifier,
                       PackageIdentification?, Route*, Contact*, Comments*,
                       Extrinsic*)>
<!ATTLIST ShipControl
    startDate            %datetime.tz;         #IMPLIED
>

<!--
    Identifiers which appear on the containers, skids, boxes or packages
    that constitute the shipment.  The range of numbers described is
    inclusive at both extremes.

    rangeBegin
        Earliest number appearing on the separate elements in this
        shipment.
    rangeEnd
        Highest number appearing on the separate elements in this
        shipment.  Must be greater than or equal to rangeBegin.
-->
<!ELEMENT PackageIdentification EMPTY>
<!ATTLIST PackageIdentification
    rangeBegin           %uint;                #REQUIRED
    rangeEnd             %uint;                #REQUIRED
>

<!--
    How the shipment will travel on this segment.  Each carrier within a
    segment controlled by a third party logistics provider provides
    tracking information to that provider externally.  The
    ShipNoticeRequest includes tracking information at the ShipControl
    level only.

    One Route element may describe only a single mode of travel.  If
    described at all, each mode of a multi-modal route must be described by
    a separate Route element.  It is not necessary to describe every leg of
    the journey to the buyer's ShipTo location.

    The only Contact roles likely to be sensible in this element are
    "carrierCorporate" (details the contact information the supplier has
    about the carrier organization), "shipFrom" and "shipTo".  The
    "carrierCorporate" role would be relevant at this level only when a
    third party is providing tracking information across multiple carriers.
    A Contact element with role "shipFrom" must appear in all Route
    elements after the first.  Route elements are not required to describe
    the entire travel under a specific carrier's control.  They may
    describe a discontinuous stream of events, starting and ending at
    different times and locations.

    Elements in the Contact list may appear in any order.  A contact role
    (Contact@role attribute value) must not appear more than once within a
    Route element.

    method
        Qualifier identifying the transportation type code:
        air - transportation by flight
        motor - transportation by land motor craft (common carrier)
        rail - transportation by rail
        ship - transportation by boat (ocean)
    startDate
        The date and time this shipment started this part of the trip.
        Required in all Route elements after the first.
    endDate
        The date and time this shipment ended this part of the trip.  Must
        be after startDate.  If any Route elements follow, the startDate of
        that element must not precede this value.
-->
<!ELEMENT Route (Contact*)>
<!ATTLIST Route
    method         (air | motor | rail | ship) #REQUIRED
    startDate            %datetime.tz;         #IMPLIED
    endDate              %datetime.tz;         #IMPLIED
>

<!--
    Purchase order and item data.  Answers the question: What's coming in
    this shipment?

    A particular OrderRequest (via the OrderReference element) must not be
    mentioned in more than one ShipNoticePortion element.  While multiple
    shipments may be sent for one order, a ship notice must mention each
    order only once.

    Any Contact elements provided at this level describe contacts specific
    to this order.  The ShipNoticeHeader description mentions roles
    appropriate at this level as well, though shipFrom, shipTo,
    buyerCorporate and supplierCorporate information should not vary at
    this level.  A particular Contact role must not appear in both the
    ShipNoticePortion and ShipNoticeHeader elements.  Therefore, roles such
    as technicalSupport, customerService and sales are most appropriate
    within the ShipNoticePortion.

    Elements in the Contact list may appear in any order.  A contact role
    (Contact@role attribute value) must not appear more than once within a
    ShipNoticePortion element.

    The Comments element list may contain additional information about the
    order in this shipment.  In this context (the ShipNoticePortion
    element), that information must be common to all contained items or
    make it clear which ShipNoticeItem is affected.  All such data must be
    intended for human use.

    Elements in the Comments list may appear in any order.  The xml:lang
    attribute may have the same value in multiple Comments elements in the
    list.  The set of Comments with a particular xml:lang value should
    contain similar content to that for any other xml:lang value present in
    the list.

    On the other hand, the Extrinsic element list may be used to insert
    additional data about this order for application consumption.  These
    elements may include pre-defined keywords and values affecting workflow
    in the receiving system.

    Elements in the Extrinsic list may appear in any order.  An extrinsic
    type (Extrinsic@name attribute value) must not appear more than once
    within a ShipNoticePortion element.  A type may not be mentioned both
    in this list and in the overall ShipNoticeHeader element.  (The
    ShipNoticeHeader must not contain a default extrinsic value overridden
    at this lower level.)

    If a ShipNoticePortion element contains no ShipNoticeItem elements, the
    entire referenced order is included in the shipment.  Note: This
    simplifying option prevents inclusion of hazard and packaging
    information.
-->
<!ELEMENT ShipNoticePortion
    (OrderReference, Contact*, Comments*, Extrinsic*, ShipNoticeItem*)>

<!--
    Portion of a specific line item that is part of this shipment.

    A line item from an order must not be mentioned in more than one
    ShipNoticeItem element.  While additional quantities of an item may be
    shipped separately, a single ship notice must describe each item only
    once.

    Elements in the Hazard list may appear in any order.  The same hazard
    should not be listed more than once in a ShipNoticeItem.  Each hazard
    listed at this level (in a ShipNoticeItem element) must apply to this
    specific line item.  A ShipNoticeRequest for a single line item should
    not include Hazard elements in the ShipNoticeItem element.

    quantity
        Number of this line item which was shipped.  Expressed in the units
        given in the UnitOfMeasure element.
    lineNumber
        Position (counting from 1) of this item in an order.  Copied
        directly from the corresponding line item (ItemOut) in the document
        referenced in the sibling OrderReference element.
-->
<!ELEMENT ShipNoticeItem (UnitOfMeasure, Packaging?, Hazard*)>
<!ATTLIST ShipNoticeItem
    quantity             %r8;                  #REQUIRED
    lineNumber           %uint;                #REQUIRED
>

<!--
    Details about the packaging of this line item.

    Zero or more PackagingCode elements may appear in the Packaging
    element.  Each PackagingCode must contain a single string corresponding
    to the packaging for this item.  When multiple PackagingCode elements
    appear, all must describe the same packaging in different languages or
    locales.  (No two PackagingCode elements may have the same xml:lang
    attribute.)  Elements in such a list may appear in any order.

    The dimensions mentioned in the Dimension element list may appear in
    any order.  A particular dimension (Dimension@type attribute value)
    must not appear more than once in a Packaging element.
-->
<!ELEMENT Packaging ((PackagingCode+, Dimension*) | Dimension+)>

<!--
    One language-specific code for the packaging of this item.  Values such
    as "pallet", "skid" and "truck load" may be appropriate (for an
    English-based locale).

    xml:lang
        The language or locale in which the PackagingCode content (the
        value of the code) is written.
-->
<!ELEMENT PackagingCode (#PCDATA)>             <!-- string -->
<!ATTLIST PackagingCode
    xml:lang             %xmlLangCode;         #REQUIRED
>

<!--
    A single dimension for the packaging of this item.

    quantity
        Size in this dimension.  Expressed in the units given in the
        UnitOfMeasure element.
    type
        Type of dimension.  Supported values include:
        length - The length of the packaging.
        width - The width of the packaging.
        height - The height of the packaging.
        weight - The weight of the packaging.
        volume - The volume of the packaging.
-->
<!ELEMENT Dimension (UnitOfMeasure)>
<!ATTLIST Dimension
    quantity             %r8;                        #REQUIRED
    type (length | width | height | weight | volume) #REQUIRED
>
<!--
    For cXML license agreement information, please see
    http://www.cxml.org/home/license.asp

    $Id: //ariba/cxml/Modules/Transport.mod#14 $
-->

<!--
    For better definitions of these Elements/Entities, refer to the cXML
    Protocol Specification documents.
-->

<!--
    cXML envelope

    version
        Version of this cXML transmission.  Should be less than or equal
    to the version portion of the SYSTEM identifier for this document.

    payloadID
        A unique identifier for this document.

    timestamp
        The date and time at which this document was originally created.

    xml:lang
        The default locale for all strings (not formatted items such as
    dates, times and numbers) in this document.  This attribute will be
    required in a future version of cXML.  (Leaving it out is
    deprecated.)
-->
<!ELEMENT cXML (( Header, (Message | Request)) | Response)>
<!ATTLIST cXML
    version    %string;       "&cxml.version;"
    payloadID  %string;       #REQUIRED
    timestamp  %datetime.tz;  #REQUIRED
    xml:lang   %xmlLangCode;  #IMPLIED
>

<!-- header -->
<!ELEMENT Header (From, To, Sender, (Path, OriginalDocument)?)>

<!ELEMENT From (Credential+)>
<!ELEMENT To (Credential+)>
<!ELEMENT Sender (Credential+, UserAgent)>

<!--
    Path. A list of nodes that records the path taken by a user through 
    a punchout chaining scenario.
-->
<!ELEMENT Path (Node+)>

<!--
    A Node is any entity connected to a Network.
    
    type
        A node can define itself as a router node or a copy node.  Routers
    assume responsibility for the transaction.  Copy Nodes request to only
    be aware of the transaction.
    
    itemDetailsRequired
        Intermediary Nodes may want to support special operations without
    having to store specific information required to fulfill that operation.
    This attribute tells the previous node to send ItemDetail information
    when performing a PunchOutSetupRequest edit/inspect operation.
-->
<!ELEMENT Node (Credential+)>
<!ATTLIST Node
    type (copy | route) #REQUIRED
    itemDetailsRequired (yes) #IMPLIED
>


<!--
    Identifies the previous document in the situation that a router node
    forwards a message or request on to a more distant node.
    
    payloadID
        The payloadId of the original document.
-->
<!ELEMENT OriginalDocument EMPTY>
<!ATTLIST OriginalDocument
    payloadID %string; #REQUIRED
>

<!--
    A textual string representing who the UserAgent is conducting the cXML
    conversation. Analogous to UserAgent for HTTP conversations.
-->
<!ELEMENT UserAgent (#PCDATA)>

<!--
    A digital signature.  The recommended format is self-contained PK7. The
    exact signed content is not that significant but current timestamp would
    be used just as a convention.

    type
        The type of digital signature used.

    encoding
        How is the signature encoded in the XML stream.
-->
<!ELEMENT DigitalSignature ANY>
<!ATTLIST DigitalSignature
    type      %string;  "PK7 self-contained"
    encoding  %string;  "Base64"
>

<!--
    A shared secret. Typically, this is a username/password type of secret
    exchanged through a secure transport before communication takes place.
-->
<!ELEMENT SharedSecret ANY>

<!--
    Represents an identity for a credential.

    lastChangedTimestamp
       When the underlying object last changed in the originating system.
       This is used in cases where the same object (e.g. a buyer
       organization) is replicated, and kept synchronized, across two
       systems.
-->
<!ELEMENT Identity ANY>
<!ATTLIST Identity
    lastChangedTimestamp  %datetime.tz;  #IMPLIED
>

<!--
    A Credential Message Authentication Code (MAC).  This is used in
    situations where one party (the sender) must prove to another (the
    receiver) that it is authenticated by a shared secret with a third
    party trusted by both.

    The MAC should be computed by the trusted third party and
    transferred to the sender.  The MAC should be opaque to the sender
    (i.e., it should be secure and non-reversible).  The MAC should
    use as its inputs enough information to accomplish the following
    goals:

    (1) The MAC must prove to the receiver that it really originated
    with the trusted third party.  E.g., the MAC could use a shared
    secret between the receiver and the trusted third party as its
    secret key.

    (2) The MAC should be usable only by a certain sender.  E.g., the
    MAC could authenticate an identifier for the sending organization.

    (3) The MAC should prove that the sender is authorized to send on
    behalf of the From organization.  E.g., the MAC could authenticate
    an identifier for the From organization.

    (4) The MAC should limit the risk of the MAC being compromised and
    used to impersonate the sender by another party communicating with
    the receiver.  E.g., the MAC could authenticate an expiration date
    or sequence number.

    type
        An implementation-dependent identifier for the exact data
        being authenticated and the method in which it is formatted
        for authentication.  Currently the only supported value is
        "FromSenderCredentials".

    algorithm
        An implementation-dependent identifier for the exact MAC
        algorithm used on the data.  Currently the only supported
        value is "HMAC-SHA1-96".

    creationDate
        The time at which this MAC was issued.  The receiver must not
        accept the MAC before this time.

    expirationDate
        The time at which this MAC expires.  The receiver must not
        accept the MAC after this time.
-->
<!ELEMENT CredentialMac (#PCDATA)>
<!ATTLIST CredentialMac
    type           %string;      #REQUIRED
    algorithm      %string;      #REQUIRED
    creationDate   %datetime.tz; #REQUIRED
    expirationDate %datetime.tz; #REQUIRED
>

<!--
    A combination of an Identity and authentication element. If the
    authentication element is present, it strongly authenticates who/what
    someone is.  The authentication element should not be sent within Message
    documents transported via an end user's browser.  One-way communication
    must be authenticated in the transport layer.

    domain
        In what domain is this Credential represented?
    type
        Does this Credential identify a marketplace or one of its member
        companies?  A Credential without this attribute describes a member
        company or unaffiliated buying organization.
-->
<!ENTITY % cxml.authentication  "SharedSecret |
                                 DigitalSignature |
                                 CredentialMac"
>
<!ELEMENT Credential (Identity, (%cxml.authentication;)?)>
<!ATTLIST Credential
    domain  %string;      #REQUIRED
    type    (marketplace) #IMPLIED
>

<!--
    Status of a Response or Message.  If present, the element content
    describes specifics of a problem.

    code
        HTTP or cXML-specific status code.

    text
        Textual version of the status code (not specific issue).

    xml:lang
        The language in which the text attribute and element content are
    written.  This attribute will be required in a future version of
    cXML.  (Leaving it out is deprecated.)
-->
<!ELEMENT Status (#PCDATA)>
<!ATTLIST Status
    code     %uint;        #REQUIRED
    text     %string;      #REQUIRED
    xml:lang %xmlLangCode; #IMPLIED
>

<!--
    Message

    When Status not present, '<Status code="200" text="OK" />' is implied.
-->
<!ELEMENT Message (Status?, %cxml.messages;)>
<!ATTLIST Message
    deploymentMode  (production | test)  "production"
    inReplyTo       %string;  #IMPLIED
>

<!-- request -->
<!ELEMENT Request (%cxml.requests;)>
<!ATTLIST Request
    deploymentMode  (production | test)  "production"
>

<!-- response -->
<!ELEMENT Response (Status, (%cxml.responses;)?)>