Root element of a Process Specification document that has a globally unique identity. The Process Specification element can specify the version of the technical specification used and the process instance version related to the target ebBP (schema). Is the technical specification version of the Process Specification. Note: This attribute was added in v2.0. Is the version of the Process Specification or artifact instance. An example would be the Australian Wheat Board v2.1. Note: This attribute was added in v2.0. Type for the root element of a Process Specification document. Defines a string identification mechanism for a Process Specificiation. The uuid is not used for the purpose of versioning, so that even a change introduced by AttributeSubstitution (to business documents’ schemas, for example), would be marked by a new uuid. Defines a hierarchical name scope containing reusable elements. Type for a hierarchical name scope containing reusable elements. Defines the nameID reference for a Package. Defines user documentation for any element. Must be the first element of its container. Note: The xml:lang was added in v2.0. Type for the user documentation for any element. Defines the address of the Documentation object. A URL can be a URI. Attribute or document value should be used in place of some value in an existing Process Specification. Attribute substitution could be used for document substitution. These substititution changes were made in v2.0. Type for the attribute or document value used for substitution. Is the nameID reference to the Documentation related to a particular element. Is the name of an attribute of any element within the scope of the substitution set. Is the value, which shall replace the current value of the attribute. External role element maps to the actual roles used in a Business Collaboration (for example, an external role maps to a Business Collaboration). Note: This element was added in v2.0. Types for the external role that maps to actual roles in a Business Collaboration. Performs elements are needed when the values of Roles declared in a Business Collaboration differ from the values declared with the @name attribute. Note: This complexType was added in v2.0. Each business partner plays one or more abstract partner roles in the Business Collaboration. The group that includes the various types of Collaborations. Note: The Business Collaboration will replace the Binary and MultiParty Collaboration in a future version. Note: This group was added in v2.0. Two roles - Defines the interaction between two top-level or abstract partner roles. Binary Collaboration is a choreographed state of two Business Collaboration roles. This Business Collaboration is being deprecated. The type related to Binary Collaboration. May point to the pattern on which an activity or collaboration is based. This attribute is used only when not using the concrete BT patterns provided. Indicates whether or not this Business Collaboration definition can only be used within a Collaboration Activity (as a sub collaboration) or initiated directly by a party. More than two roles - Defines the interaction between more than two top-level or abstract partner roles. Binary Collaboration is a choreographed state of more than two Business Collaboration roles. This collaboration is being deprecated. The type related to MultiParty Collaboration. May point to the pattern on which an activity or collaboration is based. This attribute is used only when not using the concrete BT patterns provided. Indicates whether or not this Business Collaboration definition can only be used within a Business Collaboration activity (as a sub collaboration) or initiated directly by a party. Two or more roles - Two or more roles - Defines the interaction between two or more top-level or abstract partner roles. Binary Collaboration is a choreographed state of two or more Business Collaboration roles. This element will replace Binary and MultiParty Collaboration elements in a future version. The type related to Business Collaboration. May point to the pattern on which an activity or collaboration is based. This attribute is used only when not using the concrete BT patterns provided. Indicates whether or not this Business Collaboration definition can only be used within a Collaboration Activity (as a sub collaboration) or initiated directly by a party. Conveys business information between two roles in a business transaction. One document envelope conveys the request from the Requesting to the Responding role and another the response from the Responding role back to the Requesting one (where applicable). The Type related to envelope that conveys business information. Indicates the nameID reference to the logical business document. May evaluate to TRUE or FALSE. If TRUE, the DocumentEnvelope is intended as a positive response to a request. The value for this parameter is used to evaluate a Business Success or Failure of the corresponding Business Transaction. A generic name of a document. A Business Document may have 0..n Condition Expressions. The type related to a Business Document. An optional unstructured document associated with a Business Document. Indicates the nameID reference to the logical business document. Defines the valid MIME (Multipurpose Internet Mail Extensions) type of this Attachment. Example: 'application/pdf'. Defines the minimum occurrences of an Attachment. Note: This attribute was added in v2.0. Defines the maximum occurrences of an Attachment. Note: This attribute was added in v2.0. A specification element that can associate many references to a particular ebBP element. For example, multiple specifications associated with a logical Business Document. Note: This element was added in v2.0. This attribute defines the type of the Specification of the particular ebBP element. Note: This attribute was added in v2.0. The location of the Specification of the particular ebBP element. Note: This attribute was added in v2.0. The target namespace of the Specification of the particular ebBP element. Note: This attribute was added in v2.0. A name, URN or other reference that cites an external specification or reference that defines the document. This attribute was added during v2.0.1 Public Review and included in v2.0.2. Defines a Business Transaction Activity within a Business Collaboration. A Business Transaction Activity is a business activity that executes a Business Transaction. Note in v2.0, isLegallyBinding was replaced by hasLegalIntent. The type related to a Business Transaction Activity. The BusinessTransactionActivityType reuses previously defined Business Transactions. Performs elements are required to bind Role values to the Requesting and Responding activities. The older initiatingRoleIDRef attribute is removed as insufficiently versatile. Note: This complexType was added in v2.0. The nameID reference for the Business Transaction. This attribute is used to reference the Business Transaction reused by the BusinessTransactionActivityType. Indicates that a particular activity that could represent a statement or commitment between trading partners, and their shared intent. Note: This attribute was renamed to hasLegalIntent from isLegallyBinding in v2.0. A parameter that governs the flow of transactions. Unlike the security and timing parameters it does not govern the internal flow of a transaction, rather it determines whether at run-time multiple instances of that Business Transaction Activity can be ‘open’ at the same time within any Business Collaboration instance performed between any two partners. isConcurrent limits the ability to execute multiple BTA of the same BT across Business Collaboration instances (with the same party), or within the same Business Collaboration if multiple paths are open. As a result, when isConcurrent is set to false, the BSIs of each party are responsible for serializing these Business Transaction activities. Defines a new descriptive element that holds an embedded activity that allows recursive embedded activities. This construct is restricted to 'black box' visibility (i.e. the embedded activity is used for visibility only not for a Multiparty Collaboration). The subparties in the ComplexBTA are auxiliary partners (not constrained by the Business Collaboration). Note: The ComplexBTA and other linking constructs replaced the onInitiation flag in v2.0. Information (which can be aggregated) returned by the subparties of an embedded Business Transaction Activity or ComplexBTA for visibility purposes to the outermost ComplexBTA. For example, a subparty (requester in an embedded BTA that is responder in ComplexBTA) returns aggregated supplier information to the ComplexBTA prior to the responder issuing an order response. The Status Visibility element specifies which status values and which Document Envelope events of the embedded processes are considered, if any, when returning the status value to the context of the ComplexBTA. If no status values or DocumentEnvelope events can be monitored, then both BusinessDocumentList and SubstateVisibility are omitted. Note, this element was added in v2.0. The activity of performing a Business Collaboration within another Business Collaboration. The type related to a Collaboration Activity. The nameID reference for the Business Collaboration performed by the Collaboration Activity. A linking construct that indicates a state that can be transitioned from in the current context (containing element). The FromLink/@fromBusinessStateRef attribute references the state that is transitioned from by its ID value. FromLinks can have 0..n Condition Expressions associated with them. The conditionGuard attribute can contain status values obtained from the state pointed to by the FromLink; matching the value governs whether a transition is made at run time. Note: This element was added in v2.0. The nameID reference of the Business State of the link transitioned from. The condition that guards the transition from a Business State. A linking construct that indicates states that the current context (containing element) can transition to. The ToLink/@toBusinessStateRef attribute value references the state through its ID value. Completion States can have 0..n ConditionExpressions that are checked at runtime to determine whether the transition to a state is actually made. Note: This element was added in v2.0. The nameID reference of the Business State of the link transitioned to. The type related to the linking constructs (TO and FROM). The type can have 0..n Condition Expression associated with it. Note: The linking constructs on a transition replaced the onInitiation flag in v2.0. An expression element that can be evaluated and provide a TRUE or FALSE. Multiple Condition Expression languages and expressions can be used. Note: The capability whereby multiple Condition Expression languages and expressions can be used was expanded (as well as its use with variables) in v2.0. The type related to the ConditionExpression element. A BSI supports at least the XPath language, as well as the DocumentEnvelope (expressionLanguage of ExpressionLanguageType) which is the nameID of a Document Envelope. In previous versions, this was known as DocumentEnvelopeNotation. When variables are used, XPath and XSLT could be beneficial. Note: This complexType was added in v2.0. Defines the language used for the Condition Expression. Defines the value for the Condition Expression. Allows a default value to be specified for the Condition Expression. This default value is expressed as an xsd:string. To acquire an xsd:boolean, an XSLT constant boolean function of TRUE or FALSE may be used. The specific Collaboration started with to traverse a path through a graph to a Completion State. The type related to the Start of a specific Collaboration type within the Collaboration Group. A link between business states in a Business Collaboration. Choreography is expressed as transitions between business states. Transition to the same business state is allowed. The type related to the traverse between business states. A particular pattern of transition between business states. For example, a choice. This is similar to a Decision in a UML activity diagram, although precise semantics differ. One incoming link and many outgoing links, only one of which is taken. The type related to a Decision construct. A choreography construct with one incoming transition and many outgoing transitions. All outgoing transitions are considered to happen either in parallel or, when indicated, an exclusive OR is operative. The type related to the Fork construct Defines the type of Fork. OR: An OR value will mean that any business activity pointed to by a transition coming from the fork might be initiated. All activities may run in parallel. XOR: Only one of the possible activities will run. A choreography construct that defines the point where one or more forked activities join. Can define that the completion of all state occur. The type related to the Join construct Indicates that all transitions coming into the Join are executed in order for the Business Collaboration to reach the Join state (AND-join). By default, the Join is an AND-join. Defines a successful completion of a Collaboration as a transition from an activity. Defines a failure completion of a Business Collaboration as a transition from an activity. The type related to the Success for Failure completion of a Business Collaboration as a transition from an activity. An abstract superclass that holds the attributes common to the Requesting and Responding Business Activity. The type related to the Business Action. A Business Action performed by the Requesting role within a Business Transaction. The type related to the Requesting Business Action. A Business Action performed by the Responding role within a Business Transaction. The type related to the Responding Business Action. The type related to the Business Transaction Activity or Collaboration Activity types (and business state). Performs elements are required whenever referencing the RequestingBusinessActivity or RespondingBusinessActivity in a BTA or within the BTAs of a ComplexBTA. Also Performs elements are required when the Role values in a referring context differ from or need to be switched between the Role values in the referenced context. (The main referring contexts for Business Collaborations are the content models of the CollaborationActivity and ExternalRoles elements.The BTAs and ComplexBTAs are the other referring contexts.) For example, in a Business Collaboration between two parties is related to another Business Collaboration (also of two parties) using a Collaboration Activity, the roles may change for the involved parties. Those roles are traced and associated with the parties. This functionality supports tracing and binding of roles of the Business Collaboration across and within multiple levels of nesting. Where allowed, the Performs element may be omitted if the actual values of Roles in the referring and referred-to context are the same (i.e. string identical) and they match. Note: This element was added in v2.0. The type related to the role binding Performs element. The currentRoleRef attribute defines the nameID reference of the specific role currently used in an activity. If roles change, this name ID reference for the currently used role is the referring role that is linked to the referred-to role in the performsRoleRef. The performsRoleRef attribute defines nameID reference of the referred-to role for the specific role used in an activity. This referred-to role is bound to the referring role (currentRoleRef). The type related to the Role of a Business Collaboration. For example, in a Business Collaboration, two or more top-level roles apply. The Role Type is a global element, that allows Role elements to be defined of Role Type. The abstract superclass associated with the concrete set of defined Business Transaction patterns. A Business Transaction is a set of business information and Business Signal exchanges amongst business partners that occurs in an agreed upon format and sequence (as supported by the patterns). Through the Business Transaction Head, the concrete set of BT patterns and the Data Exchange element (which allows pattern specialization) enable business exchange through a defined pattern. The Business Transaction Head in essence is a placeholder where the concrete pattern is substituted (i.e. a Request-Confirm is substituted and used). Note: The Business Transaction Head replaced the Business Transaction element in v2.0. The type related to the abstract superclass associated with Business Transactions. Allows definition of the Requesting declarative role on the Business Transaction. This explicit, yet abstract, role facilitates role mapping. This element was added in v2.0.1. Allows definition of the the Responding declarative role on the Business Transaction. This explicit, yet abstract, role facilitates role mapping. This element was added in v2.0.1. May point to the pattern on which the Business Transaction is based. This attribute is used only when the concrete BT patterns provided are not used. This attribute is retained for backward compatibility. The concrete Business Transaction patterns are also specified. This attribute is not be used if one of the concrete, extensible (Data Exchange) or Legacy Business Transaction (used for conversion purposes only) patterns are used. Note: These changes were made in v2.0. Refers to the expectation that the underlying messaging service used to implement the Business Transaction protocol provides guaranteed delivery, i.e. reliable messaging. The Business Transaction of type BusinessTransactionType is based on the Commercial Transaction pattern. This pattern (and the two elements that map to it) is typically a formal obligation between parties. Historically, the Commercial Transaction (as one of the defined patterns) has been colloquially known as the Business Transaction. Note: This element that maps to the Commercial Transaction pattern (i.e. the complex type BusinessTransactionType) was added in v2.0. The Commercial Transaction is based on the Commercial Transaction pattern. This pattern (and the two elements that map to it) is typically a formal obligation between parties. Historically, the Commercial Transaction (as one of the defined patterns) has been colloquially known as the Business Transaction. Note: This element that maps to the Commercial Transaction pattern (i.e. the complex type BusinessTransactionType) was added in v2.0. Either the Commercial Transaction or the Business Transaction elements map to type BusinessTransactionType that relates to the Commercial Transaction pattern. The type BusinessTransactionType alllows different communities to use the Commercial Transaction pattern via the two elements that map to it - Commercial Transaction or Business Transaction. Note: This complexType was added in v2.0. A concrete Business Transaction Pattern where an initiating party requests information about their status of a previous request or a Responder's business rules. Typically no residual obligation between parties applies. For example, an initiating party could request authorization to sell specific products where a confirmation response is expected. Note: This concrete pattern was added in v2.0. A concrete Business Transaction Pattern where there is typically no residual obligation between the parties. The Request-Response Business Transaction Pattern can be used when an initiating party requests information the Responding party already has. This pattern is used when a complex set of interrelated results are required; otherwise use Query-Response. Typically no residual obligation between parties applies. For example, a request for price and availability. Note: This concrete pattern was added in v2.0. A concrete Business Transaction Pattern where the Requester queries for information the Responder already has. The response meets the specified constraining criteria. If a complex set of interrelated results are required, use Request-Response Business Transaction Pattern. Typically no residual obligation between parties applies. Note: This concrete pattern was added in v2.0. A concrete Business Transaction Pattern where an informal exchange occurs between parties. Typically no residual obligation between parties applies. No Responding Business Document (response) applies. It is important to note that in this pattern there is a Responding Business Activity and corresponding Responding Role irrespective of the fact there is not a Responding Business Document. That Responding role receives and processes (in an abstract sense) the Request. The Responding Business Activity binds the associate role to the business action. Each activity, Requesting or Responding, has roles bound and linked to it. Note: This concrete pattern was added in v2.0. A concrete Business Transaction Pattern where there is a formal information exchange between parties that may affect the previous completion of a Commercial or Business Transaction (of the BusinessTransactionType). For example, when the Notification pattern is used for the Notification of Failure Business Transaction, this involves a business message. Another example of a business notification is an Advance Ship Notice. It is important to note that in this pattern there is a Responding Business Activity and corresponding Responding Role irrespective of the fact there is not a Responding Business Document. That Responding role receives and processes (in an abstract sense) the Request. The Responding Business Activity binds the associate role to the business action. Each activity, Requesting or Responding, has roles bound and linked to it. Note: This concrete pattern was added in v2.0. The element is open and allows definition of other patterns unspecified in the concrete set of Business Transaction patterns. The DataExchange element was not constrained to support state alignment. The semantics related to DataExchange are partner-specific and therefore left unspecified. Note: This element was added in v2.0. The previous Business Transaction (now called LegacyBusinessTransaction) was retained for conversions only. The previous Business Transaction element is being replaced by the Business Transaction Head abstract superclass, BusinessTransactionBaseType and the concrete set of Business Transaction Patterns. Note: The Business Transaction (LegacyBusinessTransaction) will be deprecated in a future version. This element was retained in v2.0.x versions. As a Business Action, this element defines the identification structure for Business Signal messages to be sent to a trading partner. Note: This element was explicitly added for Business Signals to mirror structure of the Business Document specification. This Business Action is non-substantive. A Business Signal is used for state alignment. Note: This element was added in v2.0. The type of a Signal Envelope definition that conveys Business Action information. This type for Business Signals mirrors the Document Envelope structure (where applicable). A Business Signal is used for state alignment. Note: This type was added in v2.0. The nameID reference of the Business Signal definition for the Business Signal. Note: This attribute was added in v2.0. The type of a Signal element. A Business Signal is used for state alignment. This construct allows specification references (such as those used for context), and a Signal Type may have 0..n Condition Expression. Note: This type was added in v2.0. The type of Business Action Business Signal of positive Receipt Acknowledgement. A Business Signal is used for state alignment. Note: This type was added in v2.0. ReceiptAcknowledgementType specifies whether positive receipt of a Business Signal is required (i.e. the Business Signal is not an exception). Note: This attribute was added in v2.0. The type of a BusinessAction Business Signal of exception Receipt Acknowledgement. A Business Signal is used for state alignment. Note: this type was added in v2.0. For ReceiptAcknowledgementExceptionType, specifies whether positive receipt of a Business Signal is not allowed (i.e. the Business Signal is an exception). Note: This attribute was added in v2.0. The type of Business Action Business Signal of positive Acceptance Acknowledgement. A Business Signal is used for state alignment. Note: This type was added in v2.0. For AcceptanceAcknolwedgmentType, specifies whether positive acceptance of a Business Signal is required (i.e. the Business Signal is not an exception) Note: This attribute was added in v2.0. The type of a BusinessAction Business Signal of exception Acceptance Acknowledgement. A Business Signal is used for state alignment. Note: This type was added in v2.0. For AcceptanceAcknowledgementExceptionType, specifies whether positive acceptance of a Business Signal is not allowed (i.e. the Business Signal is an exception). Note: This attribute was added in v2.0. The type of a Business Action of general exception (exceptions other than Receipt and Acceptance Acknowledgement). During an interaction, if specified by the parties, the general exception may be used when a party has to trigger an exception, for example, for a general communication of catastrophic failure. A Business Signal is typically used for state alignment. As an unforeseen event, this type of Exception is outside of the currently defined concrete BT patterns. Note: this type was added in v2.0. For GeneralExceptionType, specifies whether positive receipt of a Business Signal is not allowed (i.e. the Business Signal is an exception). Note: This attribute was added in v2.0. The expected time available to successfully complete a specified activity such as a substantive response to a request. The Time To Perform could be a variable, i.e. it can be specified at different points during the process lifecycle. Note: This element was added (previously was an attribute on specific elements) in v2.0; capabilities were also added for late binding. The duration of the maximum amount of time between the time at which the request is sent and the substantive response is received. Note: This attribute was added in v2.0. The type as specified by the simpleType of TimeToPerformType. Note: This attribute was added in v2.0. A semantic element that supports the effective use of conditional constraints. The variable can be accessed by external elements. The businessTransactionActivityRef and businessDocumentRef point to what context and documents are relevant to Condition Expression evaluation. Variable assumes type, if any, from expression evaluation. This element, for example, could be associated with a logical Business Document. Given whether simple or complex variables are used, XPath or XSLT could be used, for example. Note: This complexType was added in v2.0. Exactly one ConditionExpression is used to provide values. If multiple ConditionExpressions are listed, each expressionLanguage value is different from others in the sequence and distinct. The nameID reference of the Business Transaction Activity associated with the semantic variable. Note: This attribute was added in v2.0. The nameID reference of the logical business document associated with the semantic variable. Note: This attribute was added in v2.0. An abstract element that allows mapping a BTA and its BusinessDocuments to Interface/Operation messages. Specifies input, output, fault, interface, operation map to role, BTA and document envelope or Business Signal references. Note: This element was added in v2.0. The type related to the abstract element mapping Operations to Business Actions, either business messages or signals. Note: This complexType was added in v2.0. Maps to a Role element contained in collaboration. The simpleType related to the definition of Time To Perform during the process lifecycle. Allows for late binding. Note: This simpleType was added in v2.0. The simpleType related to the (future) enumerated list for the Business Document list associated with the Status Visibility element. This simpleType is used in exposing visibility to documents from more deeply nested BTA. Thoses values are to be available as the expression language listed. Note: This simpleType was added in v2.0. The simpleType related to the content model for Status Visibility. Note: This simpleType was added in v2.0. The simpleType related to the enumerated list for the guard values associated with the FromLink in a Completion State. Each of the FromLinks in a Completion State can be specified to transition as a result of the ConditionGuardValues. This check is made every time a transition occurs from the real states. Because the FromLinks generally are from a specific state, only when that state has been reached is the check of conditionGuards from that state checked. Business Success and Failure relate to the business documents received. While conversely, any timeout is a business protocol failure, i.e. the state is not aligned. Note: This simpleType was added in v2.0. The simpleType related to the enumerated list of specification types for the Specification element. Note: This simpleType was added in v2.0. The simpleType related to the enumerated list of operation types supported by OperationMapping and OperationMappingType. Note: This simpleType was added in v2.0. This simpleType relates to the types of Expression language. An enumerated list is provided. Note: This simpleType was added in v2.0. The attributeGroup related to document security, quality of service attributes. These attributes relate to the BT patterns and the operational semantics surrounding their use. The communications channel used to transport the Message provides transient authentication. The specific method will be determined by the communications protocol used. Persistent authentication means the Business Document signer’s identity is verified at the receiving application level. Authentication assists in verification of role identity of a participating party. Transient confidentiality is provided by a secure network protocol, such as SSL as the document is transferred between two adjacent ebXML Messaging Service or other transport messaging nodes. Persistent confidentiality is intended to preserve the confidentiality of the message such that only the intended party (application) can see it. Transient isTamperDetectable is the ability to detect if the information has been tampered with during transfer between two adjacent Message Service Handler nodes. Persistent isTamperDetectable is the ability to detect if the information has been tampered with after it has been received by messaging node, between the messaging node and the application. Tamper detection assists in verification of content integrity between and within a participating party. The attributeGroup related to interface/operation types supported by OperationMapping and OperationMappingType. The abstract map includes the interface, operation, the step (see StepType) and the document reference. Note: This attributeGroup was added in v2.0. Interface is called portType in WSDL 1.1. The name of the interface or portType mapped logically in Operation Mapping. Note: This attribute was added in v2.0. The name of the operation mapped in the OperationMapping. Note: This attribute was added in v2.0. The name of operation step from the Step Type enumeration list for OperationMapping. Note: This attribute was added in v2.0. The nameID reference of the Document Envelope related to the OperationMapping. Note: This attribute was added in v2.0. The attributeGroup related to the identification information for most elements. For the name attribute, no white space restrictions are enforced. White space is not controlled but left to implementation to trigger faults or exceptions. Note: This group was enhanced to include not only name but nameID in v2.0. A designation that may be relevant to a business analyst but is not intended for referencing. Used for referencing, for example, for identification of elements within an ebBP instance. The optname attributeGroup related to the identification information for some elements. This allows name or nameID to be optionally used. No white space restrictions are enforced. White space is not controlled but left to implementation to trigger faults or exceptions. Note: This group was added in v2.0. The attributeGroup related to quality of service attributes. These attributes relate to the BT patterns and the operational semantics surrounding their use. Note: This attributeGroup was added in v2.0. When a party uses isAuthorizationRequired on a Requesting and/or a Responding activity accordingly, the result that [the activity] will only be processed as valid if the party interpreting it successfully matches the stated identity of the activity's [Role] to a list of allowed values previously supplied by that party. Authorization typically relates to a signed business document and the association to the role identity of the party expected for that activity. Allows partners to agree that a message is confirmed by a Receipt Acknowledgement only if it is also legible. Legible means that it has passed structure/schema validity check. The content of the receipt and the legibility of a business message (if required) are reviewed prior to the processing of the Business Document or the evaluation of Condition Expressions in the business message's Business Documents or Document Envelope. If non-repudiation of origin and content is required, then the Business Activity stores the business document in its original form for the duration mutually agreed to in an agreement. Both parties agree to mutually verify receipt of a Requesting Business Document and that the receipt is non-repudiable. The time a Responding or Requesting role has to acknowledge receipt of a Business Document. The time a Requesting and Responding role has to non-substantively acknowledge business acceptance of a Business Document. The business retry for a RequestingBusinessActivity identifies the number of retries allowed in addition to the initial request while the Time To Perform has not been exceeded.