<?xml version="1.0" encoding="utf-8"?>      <!--                                  ** OAGIS® Revision: 9.1  **               ** Date: 11 May 2007 **               ** Copyright 1997-2007, All Rights Reserved **                              This is an OAGIS® BOD XML Schema (XSD) Definition.                            License information for this file is provided in the file **OAGi License Agreement.txt** that is provided with this download package.                           For support, more information, or to report implementation bugs, please contact the Open Applications Group at xml@openapplications.org.                           XML Schema                          -->                   <!--         © Copyright 2007 Infor Global Solutions Technology GmbH and/or its affiliates and subsidiaries. All rights reserved. The   word and design marks set forth herein are trademarks and/or registered trademarks of Infor Global Solutions   Technology GmbH and/or its affiliates and subsidiaries. All rights reserved. All other trademarks listed herein   are the property of their respective owners.                 -->                   <!--    *****     Update Log     *****                 Date          By      Note        10 Apr 2008    JB      Added correct Copyright and update comments to schema.                    *****     Update End     *****                 -->                  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://schema.infor.com/InforOAGIS/2"   targetNamespace="http://schema.infor.com/InforOAGIS/2" elementFormDefault="qualified"   attributeFormDefault="unqualified">                 <xs:complexType name="BusinessObjectDocumentType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Is the schema based       inheritance for all BODs. The logical model would also include the       DataArea.</xs:documentation>     </xs:annotation>         <xs:sequence>          <xs:element ref="ApplicationArea"/>      </xs:sequence>         <xs:attribute name="releaseID" type="xs:normalizedString" use="required">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">OAGIS Release this        BOD Instances belongs or the OAGIS release that the derivative work is based        on.</xs:documentation>      </xs:annotation>        </xs:attribute>         <xs:attribute name="versionID" type="xs:normalizedString" use="optional">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Indicates the        version of the given BOD definition.</xs:documentation>      </xs:annotation>        </xs:attribute>         <xs:attribute name="systemEnvironmentCode" type="SystemEnvironmentCodeContentType"      use="optional" default="Production">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Indicates whether        this BOD is being sent in a "Test" or a "Production" mode. If the BOD is being        sent in a test mode, it's information should not affect the business operation.        However, if the BOD is sent in "Production" mode it is assumed that all test has        been complete and the contents of the BOD are to affect the operation of the        receiving business application(s).</xs:documentation>      </xs:annotation>        </xs:attribute>         <xs:attribute name="languageCode" type="LanguageCodeContentType" use="optional"      default="en-US">         <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Indicates the        language that the contents of the BOD is in unless otherwise        stated.</xs:documentation>      </xs:annotation>        </xs:attribute>        </xs:complexType>         <xs:complexType name="ApplicationAreaType">       <xs:sequence>          <xs:element ref="Sender" minOccurs="0"/>      <xs:element ref="CreationDateTime"/>      <xs:element ref="Signature" minOccurs="0"/>      <xs:element ref="BODID" minOccurs="0"/>      <xs:element ref="UserAreaMeta" minOccurs="0"/>     </xs:sequence>        </xs:complexType>         <xs:complexType name="SenderType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Identifies the sender of       the given BOD instance</xs:documentation>     </xs:annotation>         <xs:sequence>          <xs:element ref="LogicalID" minOccurs="0"/>      <xs:element ref="ComponentID" minOccurs="0"/>      <xs:element ref="TaskID" minOccurs="0"/>      <xs:element ref="ReferenceID" minOccurs="0"/>      <xs:element ref="ConfirmationCode" minOccurs="0"/>      <xs:element ref="AuthorizationID" minOccurs="0"/>     </xs:sequence>        </xs:complexType>         <xs:complexType name="SignatureType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Allows any digital       Signatures to be added to the Instance of the BOD Instance in order to sign for any       portion of the BOD content.</xs:documentation>     </xs:annotation>         <xs:sequence>          <xs:any namespace="##any" minOccurs="0"/>     </xs:sequence>         <xs:attribute name="qualifyingAgencyId" type="xs:normalizedString" use="optional"/>    </xs:complexType>         <xs:element name="ApplicationArea" type="ApplicationAreaType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Provides the information       that an application may need to know in order to communicate in an integration of       two or more business applications. The ApplicationArea is used at the applications       layer of communication. While the integration frameworks web services and middleware       provide the communication layer that OAGIS operates on top of.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="OriginalApplicationArea" type="ApplicationAreaType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">A copy of the       ApplicationArea for the original BOD that was processed. Present either as       additional reference information, or for use in identifying the BOD in situations       where a BODReference is not known.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Sender" type="SenderType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Identifies       characteristics and control identifiers that relate to the application that created       the Business Object Document. The sender area can indicate the logical location of       the application and/or database server, the application, and the task that was       processing to create the BOD.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Signature" type="SignatureType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">If the BOD is to be       signed the signature element is included, otherwise it is not. Signature supports       any digital signature that maybe used by an implementation of OAGIS. The       qualifyingAgency identifies the agency that provided the format for the signature.       This element supports any digital signature specification that is available today       and in the future. This is accomplished by not actually defining the content but by       allowing the implementation to specify the digital signature to be used via an       external XML Schema namespace declaration. The Signature element is defined to have       any content from any other namespace. This allows the user to carry a digital       signature in the xml instance of a BOD. The choice of which digital signature to use       is left up to the user and their integration needs.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="CreationDateTime" type="MetaDateTimeType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">is the date time stamp       that the given instance of the Business Object Document was created. This date must       not be modified during the life of the Business Object Document. </xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="BODID" type="MetaIdentifierType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">The BODId provides a       place to carry a Globally Unique Identifier (GUID) that will make each Business       Object Document instance uniquely identifiable. This is a critical success factor to       enable software developers to use the Globally Unique Identifier (GUID) to build the       following services or capabilities: 1. Legally binding transactions, 2. Transaction       logging, 3. Exception handling, 4. Re-sending, 5. Reporting, 6. Confirmations, 7.       Security.</xs:documentation>      </xs:annotation>        </xs:element>         <xs:element name="LogicalID" type="MetaIdentifierType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Provides the logical       location of the server and applications from which the Business Object Document       originated. It can be used to establish a logical to physical mapping, however its       use is optional. Each system or combination of systems should maintain an external       central reference table containing the logical names or logical addresses of the       application systems in the integration configuration. This enables the logical names       to be mapped to the physical network addresses of the resources needed on the       network. Note: The technical implementation of this Domain Naming Service is not       dictated by this specification. This logical to physical mapping may be done at       execution time by the application itself or by a middleware transport mechanism,       depending on the integration architecture used. This provides for a simple but       effective directory access capability while maintaining application independence       from the physical location of those resources on the network</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="ComponentID" type="MetaIdentifierType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Provides a finer level       of control than Logical Identifier and represents the business application that       issued the Business Object Document. Its use is optional. The Open Applications       Group has not constructed the list of valid Component names. A suggestion for naming       is to use the application component names used in the scenario diagrams in section       two of OAGIS. Example Components may be Inventory, or Payroll.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="TaskID" type="MetaIdentifierType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Describes the business       event that initiated the need for the Business Object Document to be created. Its       use is optional. Although the Task may differ depending on the specific       implementation, it is important to enable drill back capability. Example Tasks may       be Receipt or Adjustment.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="ReferenceID" type="MetaIdentifierType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Enables the sending       application to indicate the instance identifier of the event or task that caused the       BOD to be created. This allows drill back from the BOD message into the sending       application. The may be required in environments where an audit trail must be       maintained for all transactions.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="ConfirmationCode" type="ConfirmationResponseCodeType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Is an option controlled       by the Sender business application. It is a request to the receiving application to       send back a confirmation BOD to the sender. The confirmation Business Object       Document may indicate the successful processing of the original Business Object       Document or return error conditions if the original Business Object Document was       unsuccessful. The confirmation request has the following valid values: Never - No       confirmation Business Object Document requested OnError - OnError send back a       confirmation Business Object Document only if an error has occurred Always - Always       send a confirmation Business Object Document regardless</xs:documentation>     </xs:annotation>        </xs:element>         <xs:complexType name="ExpressionType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">ReturnCriteria       identifies the content that is to be returned, given query success. In essence, the       expression here has the effect of filtering the part(s) of the found element(s) that       are to be returned. ReturnCriteria plays no role in the query itself. That is       handled as a match against the request BOD's noun exemplar. ReturnCriteria allows       the sender of the BOD to indicate which information (down to the field level) is       requested to be returned, given that the query has been successful in matching the       exemplar to existing nouns. That is, in a GetListPurchaseOrder, if one or more       PurchaseOrders with a TotalPrice = $1M were found, ReturnCriteria tells the BOD       recipient which parts of the PurchaseOrder should be populated with content when the       response (ShowPurchaseOrder) is formulated. The expressionLanguage indicates the       expression language being used. In order for the ReturnCriteria expression to be       evaluable by the BOD recipient, the recipient must be capable of processing and       interpreting the specified expression language. XPath is the default, due to its       ubiquity among XML processing technologies. </xs:documentation>     </xs:annotation>         <xs:simpleContent>          <xs:extension base="xs:token">        <xs:attribute name="expressionLanguage" type="xs:token" use="optional"/>      </xs:extension>        </xs:simpleContent>       </xs:complexType>         <xs:complexType name="ActionExpressionType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">ReturnCriteria       identifies the content that is to be returned, given query success. In essence, the       expression here has the effect of filtering the part(s) of the found element(s) that       are to be returned. ReturnCriteria plays no role in the query itself. That is       handled as a match against the request BOD's noun exemplar. ReturnCriteria allows       the sender of the BOD to indicate which information (down to the field level) is       requested to be returned, given that the query has been successful in matching the       exemplar to existing nouns. That is, in a GetListPurchaseOrder, if one or more       PurchaseOrders with a TotalPrice = $1M were found, ReturnCriteria tells the BOD       recipient which parts of the PurchaseOrder should be populated with content when the       response (ShowPurchaseOrder) is formulated. The expressionLanguage indicates the       expression language being used. In order for the ReturnCriteria expression to be       evaluable by the BOD recipient, the recipient must be capable of processing and       interpreting the specified expression language. XPath is the default, due to its       ubiquity among XML processing technologies. </xs:documentation>     </xs:annotation>         <xs:simpleContent>          <xs:extension base="xs:token">        <xs:attribute name="actionCode" type="ActionCodeContentType" use="required"/>       <xs:attribute name="expressionLanguage" type="xs:token" use="optional"/>      </xs:extension>        </xs:simpleContent>       </xs:complexType>         <xs:complexType name="ActionCriteriaType">       <xs:sequence>          <xs:element ref="ActionExpression" minOccurs="0" maxOccurs="unbounded"/>      <xs:element ref="ChangeStatus" minOccurs="0"/>     </xs:sequence>        </xs:complexType>         <xs:complexType name="ResponseActionCriteriaType">      <xs:sequence>          <xs:element ref="ResponseExpression" minOccurs="0"/>      <xs:element ref="ChangeStatus" minOccurs="0"/>     </xs:sequence>        </xs:complexType>         <xs:complexType name="ResponseExpressionType">      <xs:simpleContent>          <xs:extension base="xs:token">        <xs:attribute name="actionCode" type="ResponseActionCodeContentType" use="required"/>       <xs:attribute name="expressionLanguage" type="xs:token" use="optional"/>      </xs:extension>        </xs:simpleContent>       </xs:complexType>         <xs:element name="ActionExpression" type="ActionExpressionType"/>    <xs:element name="ActionCriteria" type="ActionCriteriaType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Identifies with the       ActionExpression the level by carrying a value of the expressionLanguage (this is       typically XPath) within the BOD that the actionCode is to be performed. The       ChangeStatus communicates just that the Change Status. </xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Expression" type="ExpressionType"/>    <xs:element name="ResponseCriteria" type="ResponseActionCriteriaType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">ResponseCriteria       identifies the content that is to be returned, given query success. In essence, the       expression here has the effect of filtering the part(s) of the found element(s) that       are to be returned. ReturnCriteria plays no role in the query itself. That is       handled as a match against the request BOD's noun exemplar. ReturnCriteria allows       the sender of the BOD to indicate which information (down to the field level) is       requested to be returned, given that the query has been successful in matching the       exemplar to existing nouns. That is, in a GetListPurchaseOrder, if one or more       PurchaseOrders with a TotalPrice = $1M were found, ReturnCriteria tells the BOD       recipient which parts of the PurchaseOrder should be populated with content when the       response (ShowPurchaseOrder) is formulated. The expressionLanguage indicates the       expression language being used. In order for the ReturnCriteria expression to be       evaluable by the BOD recipient, the recipient must be capable of processing and       interpreting the specified expression language. XPath is the default, due to its       ubiquity among XML processing technologies. </xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="ResponseExpression" type="ResponseExpressionType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">ResponseExpression       identifies a pointer to the Component being provided as a response to a request.       This point is provided using an appropriate value of the given expressionLanguage       indicated. The actionCode is intended to indicate what has occured with the given       component and/or instance of the given component.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:complexType name="AcknowledgeType">       <xs:complexContent>         <xs:extension base="ResponseVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="CancelType">       <xs:complexContent>         <xs:extension base="ActionVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="ChangeType">       <xs:complexContent>         <xs:extension base="ActionVerbType">       <xs:attribute name="responseCode" type="ResponseActionCodeContentType"/>      </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:complexType name="ConfirmType">       <xs:complexContent>         <xs:extension base="ResponseVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="GetType">        <xs:complexContent>         <xs:extension base="RequestVerbType">       <xs:attribute name="uniqueIndicator" type="xs:boolean" use="optional"/>       <xs:attribute name="maxItems" type="xs:integer" use="optional"/>       <xs:attribute name="recordSetSaveIndicator" type="xs:boolean" use="optional"/>       <xs:attribute name="recordSetStartNumber" type="xs:integer" use="optional"/>       <xs:attribute name="recordSetReferenceId" type="xs:normalizedString" use="optional"       />         </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:complexType name="LoadType">        <xs:complexContent>         <xs:extension base="ActionVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="NotifyType">       <xs:complexContent>         <xs:extension base="ActionVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="PostType">        <xs:complexContent>         <xs:extension base="ActionVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="ProcessType">       <xs:complexContent>         <xs:extension base="ActionVerbType">       <xs:attribute name="acknowledgeCode" type="ResponseCodeContentType" use="optional"/>      </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:complexType name="RespondType">       <xs:complexContent>         <xs:extension base="ResponseVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="ShowType">        <xs:complexContent>         <xs:extension base="ResponseVerbType">       <xs:attribute name="recordSetStartNumber" type="xs:integer" use="optional"/>       <xs:attribute name="recordSetCount" type="xs:integer" use="optional"/>       <xs:attribute name="recordSetTotal" type="xs:integer" use="optional"/>       <xs:attribute name="recordSetCompleteIndicator" type="xs:boolean" use="optional"/>       <xs:attribute name="recordSetReferenceId" type="xs:normalizedString" use="optional"       />         </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:complexType name="SyncType">        <xs:complexContent>         <xs:extension base="ActionVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:complexType name="UpdateType">       <xs:complexContent>         <xs:extension base="ActionVerbType"/>     </xs:complexContent>       </xs:complexType>         <xs:element name="Acknowledge" type="AcknowledgeType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Acknowledge verb       is used to acknowledge the application receipt of a Process request. This function       conveys the result of the original request. An example of this is Acknowledge PO,       where a Process PO has been issued and the corresponding business application       acknowledges the receipt of the PO and responds with an acceptance or a counter       offer.</xs:documentation>      </xs:annotation>        </xs:element>         <xs:element name="Cancel" type="CancelType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Cancel verb is       used when the sender of the BOD is not the owner of the data, but is sending a       request for the document to be canceled.An example is the Cancel PO where the       business implications must be calculated and a simple data processing term such as       delete can not fully convey the business meaning and required processing associated       with the meaning.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Change" type="ChangeType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Change verb is       used when the sender of the BOD is not the owner of the data, but is sending a       request for the document to be changed.An example of this is Change REQUISITN, where       the original document needs to be changed based on a specific business       event.</xs:documentation>      </xs:annotation>        </xs:element>         <xs:element name="Confirm" type="ConfirmType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Confirm verb is       used to respond to a request to confirm the receipt of information by the receiving       system. The request for confirmation is set by the sending application in the       ApplicationArea Sender Confirmation field of the original BOD. The Confirm conveys       the result of the original request i.e. whether or not the message was understood       and was successfully processed. An example of this is Confirm       BOD.</xs:documentation>      </xs:annotation>        </xs:element>         <xs:element name="Get" type="GetType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Get verb is to       communicate to a business software component a request for an existing piece or       pieces of information to be returned. The Get may be paired with most of the nouns       defined in the OAGIS specification.The response to this request is the Show verb.       The behavior of a BOD with a Get verb is quite predictable across the nouns it is       paired with.The Get is designed to retrieval of information by using that       information's primary retrieval field, or key field. The Get verb may also be used       to request several documents at once. Selection Criteria:There are two types of       selection capabilities for most BOD's that use the Get verb.1) The first selection       capability is called Field-Based Selection. Within a Get-based Business Object       Document, the first Data Type that occurs in a specific BOD structure is commonly       used to provide the Field-Based Selection criteria. This is always defined within       the specific BOD and is commonly the required fields for that specific Data type.The       Field-Based Selection enables the requester to provide a value or values (in the       case of multiple required Field Identifiers), in the required fields. Then the       responding component uses those values to find and return the requested information       to the originating business software component.2) The second type of selection       capability for Get-based BODs is called Data Type Selection. Data Type selection       enables the requester to identify which Data Types within the noun are requested to       be returned in the response. The use of this capability is described for each       corresponding Data Type for all BODs that use the Get verb. The Data Types are       identified for retrieval within the Get instance of a BOD by including the name of       the Data Type in the meta data but without any Field Identifiers or Segments       identified within the Data Type. This will signify to the responding application       that all of the data that corresponds to that Data Type is to be included in the       response.If the Data Type is not requested, the Data Type identifier is not included       in the Get request and this will signify to the responding component that the Data       Type is not to be returned.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Load" type="LoadType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">This verb is used to       initiate the adding of a document or data entity to another business application.       Generally this verb is used when maintenance to the document will then pass to the       receiving application permanently. An example of this is Load Payable or Load       Receivable, where once the request is processed, the sending application has no       direct control over the document or entity again.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Notify" type="NotifyType">      <xs:annotation>          <xs:documentation source="http://www.openapplications.org/oagis/9.0">Notify is used to       inform the receiving party that an event has occurred or document has been created.       For example, a supplier may have a proposed order that is sent to a trading partner.       The noun will contain the data that has been proposed. An optional ConfirmBOD can be       sent as a response.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Post" type="PostType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Post verb is used       to describe specific processing in a more fine grained manner beyond add, change or       delete processing. An example is Post JOURNAL, where information is posted to a       general ledger set of financial records. The business use of the word is used       instead of the data processing term for the sake of clarity.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Process" type="ProcessType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Process verb is       used to request processing of the associated noun by the receiving application or       business to party. In a typical external exchange scenario a Process BOD is       considered to be a legally binding message. For example, if a customer sends a       ProcessPurchaseOrder BOD to a supplier and the supplier acknowlegdes with a positive       AcknowledgePurchaseOrder, then the customer is obligated to fullfil the agreement,       unless of course other BODs are allowed to cancel or change the original       order.</xs:documentation>      </xs:annotation>        </xs:element>         <xs:element name="Respond" type="RespondType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Respond verb is       used to communicate relative to another document. It may be used to communicate       agreement, questions, answers to a question, or disagreement with the related       document. An example is the RequestForQuote and Quote document pair. An       RequestForQuote is issued to a set of business partners. If one of the partners       needs clarification on an item, a RespondRequestForQuote is sent to the originating       partner.</xs:documentation>      </xs:annotation>        </xs:element>         <xs:element name="Show" type="ShowType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Show verb is used       when sending the information about a specific instance of a business document or       entity. The Show verb may be used to respond to a Get request or it can be used in a       publish scenario, where it pushes information to other applications based on a       business event.Although BODs based on this verb do not commonly cause updates to       occur, there may be times when the component receiving the Show decides to use the       information it receives to update. This is entirely the decision of the receiving       software component and is not forbidden.The behavior of the Show verb is quite       straight forward with one exception. The Show response to any Get request needs to       read the request carefully to ensure the response is returning the requested Data       Types.</xs:documentation>      </xs:annotation>        </xs:element>         <xs:element name="Sync" type="SyncType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Sync verb is used       when the owner of the data is passing or publishing that information or change in       information to other software components. This is to be used when the receiver of       the SyncBOD does not own the data. This verb is commonly used when mass changes are       necessary or when a publish and subscribe mechanism is used in the integration       architecture.The purposes of this verb include application integrity and ease of       data entry for the business user by enabling a single point of input.      </xs:documentation>       </xs:annotation>        </xs:element>         <xs:element name="Update" type="UpdateType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">The Update verb is       used to describe specific processing in a more fine-grained manner beyond add,       change or delete processing. An example is the update of inspection information from       one business application to another. The event is not adding a document, or changing       fields per se, it is communicating the occurrence of an event as well as the       corresponding data that accompanies the event.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:complexType name="GetListType">       <xs:complexContent>         <xs:extension base="GetType"/>      </xs:complexContent>       </xs:complexType>         <xs:complexType name="ListType">        <xs:complexContent>         <xs:extension base="ShowType"/>      </xs:complexContent>       </xs:complexType>         <xs:element name="GetList" type="GetListType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">In an effort to       simpilify the usage of the verbs the GetList verb is being deprecated as of OAGIS       9.0, the GetList will still be provided for the next three releases at which time it       is scheduled to be removed from OAGIS. As such for all new development we recommend       that you use the Get verb which may serve the same function of the GetList verb has       in the past. The purpose of the GetList verb is to enable a business software       component to request summary information for one or more occurrences of a specific       noun from another business software component. The GetList may be paired with most       of the nouns in the OAGIS specification.The response to this request is a BOD using       the List verb. The GetList is designed to retrieve multiple occurrences of data such       as all of the sales orders or all of the purchase orders within a requested range.       It does not require an exact match of the key fields in order to retrieve       information. It may use a range selection criteria with a "from" and "to" selection       capability. This behavior is quite different from the Get verb, which is designed to       retrieve a specific noun using a specific key field.The GetList verb also enables       the retrieval of information across several documents by using selection fields. An       example of this could be requesting all sales order lines for a specific item. This       type of functionality is limited to the capabilities of the responding application       and needs to be determined during the implementation project. More details on this       capability will be described below. GetList attributes: o maxitems attribute is a       number that indicates the number of maximum items to be returned. o rssave attribute       is a Boolean flag that indicates whether the result set should be saved on the       sending system if maxitems is exceeded. o rsstart attribute is a number of the       starting record for the next section of the result set. If it is omitted, it is to       be assumed the first of the maxitems. o rsref attribute is a string that represents       the implementation-specific result set identifier for subsequent requests. Selection       Criteria: There are two types of selection capabilities enabled by the BODs that use       the GetList verb. 1) Field-Based Selection Allows the requesting system to ask for       information that matches the data provided. It also allows the requestor to indicate       the information that to be returned by specifying the ReturnCriteria indicated on       the GetList Verb. 2) Range Selection Allows the requesting system to provide a range       of values for known data. This is accomplished by providing two occurances of the       Noun. The first occurance indicates the "From" the second occurance indicates the       To occurance. Again the requestor can indicate the information that to be returned       by specifying the ReturnCriteria indicated on the GetList Verb. </xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="List" type="ListType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">In an effort to       simpilify the usage of the verbs the List verb is being deprecated as of OAGIS 9.0,       the List will still be provided for the next three releases at which time it is       scheduled to be removed from OAGIS. As such for all new development we recommend       that you use the Show verb which may serve the same function of the List verb has in       the past. The purpose of the List verb is to enable a business software component to       respond to a GetList request or to proactively send a listing of summary information       containing many instances of occurrences of data for a noun to one or more other       business software components.The results of a List may then be used as is, or they       may be used to select a specific instance of a document or entity in order to issue       a detail Get request.Although BODs based on this verb do not commonly cause updates       to occur, there may be times when the component receiving the List decides to use       the information it receives to update. This is entirely the decision of the       receiving software component and is not forbidden.The behavior of the List verb is       quite straight forward with a few exceptions. The List response to any GetList       request needs to read the request carefully to ensure the response is returning the       requested Data Types. The List needs to ensure the response to the GetList does not       exceed the maxItems value.The List needs to find the specific Field Identifiers that       are used for the Field-Based Selection or Range-Based Selection and process them       accordingly. The attributes associated with the List BODs are as follows: o rsstart       attribute is a number that idicates the starting record for the section of the       resulting set returned in the list message. This value should always match the       rsstart value in the originating GetList BOD. o rscount attribute is a number that       indicates the number of records returned in the message. The subsequent request for       additional records should have a rsstart value of rscount + 1. o rstotal attribute       is a number that indicates the total number of records in the result set. o       rscomplete attribute is a Boolean that indicates that the list provided exhaust the       possible values. o rsref attribute is a string that represents the       implementation-specific result set identifier for subsequent requests.      </xs:documentation>       </xs:annotation>        </xs:element>         <xs:element name="Create" type="ActionVerbType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">In an effort to       simpilify the usage of the verbs the Create verb is being deprecated as of OAGIS       9.0, the Create will still be provided for the next three releases at which time it       is scheduled to be removed from OAGIS. As such for all new development we recommend       that you use the Process verb which may serve the same function of the Create verb       has in the past. The Create verb is used to describe specific processing in a more       fine grained manner beyond add, change or delete processing. This is generally used       when the processing is initiating the building of a document, rather than moving a       document from one system to another. Examples of this include Create PRODORDER and       Create BOM. In these cases, the documents have not been constructed and need to be.       This differs from the Add PO or Add REQUISITN processing as those requests refer to       a document that has already been established and the document is being communicated       to another business application.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Receive" type="ActionVerbType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">In an effort to       simpilify the usage of the verbs the Receive verb is being deprecated as of OAGIS       9.0, the Receive will still be provided for the next three releases at which time it       is scheduled to be removed from OAGIS. As such for all new development we recommend       that you use the Process verb which may serve the same function of the Receive verb       has in the past. The Receive verb is used to describe specific processing in a more       fine grained manner beyond add, change or delete processing. An example is       ReceivePurchaseOrder, where a Purchase Order that has been issued and processed has       shipments received against it. The use of the data processing term, change, is not       specific enough in the business context.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Add" type="ActionVerbType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">In an effort to       simpilify the usage of the verbs the Add verb is being deprecated as of OAGIS 9.0,       the Add will still be provided for the next three releases at which time it is       scheduled to be removed from OAGIS. As such for all new development we recommend       that you use the Process verb which may serve the same function of the Add verb has       in the past. The Add verb is used to initiate the adding of a document or data       entity to another business application. Add is used when the sender of the BOD is       not the owner of the data, but is sending a request for the document to be created       on by the system that is the owner of the data.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Issue" type="ActionVerbType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">In an effort to       simpilify the usage of the verbs the Issue verb is being deprecated as of OAGIS 9.0,       the Issue will still be provided for the next three releases at which time it is       scheduled to be removed from OAGIS. As such for all new development we recommend       that you use the Process verb which may serve the same function of the Issue verb       has in the past. This verb is used to describe specific processing in a more fine       grained manner beyond add, change or delete processing. An example is the issue of       material from inventory. The business use of the word is used instead of the data       processing term for the sake of clarity.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:element name="Allocate" type="ActionVerbType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2.0">In an effort to       simpilify the usage of the verbs the Allocate verb is being deprecated as of OAGIS       9.0, the Allocate will still be provided for the next three releases at which time       it is scheduled to be removed from OAGIS. As such for all new development we       recommend that you use the Process verb which may serve the same function of the       Allocate verb has in the past. The Allocate verb is used to describe specific       processing in a more fine grained manner beyond add, change or delete processing. An       example of this is the allocating of costs from one business application or entity       to another. The business oriented word is used instead of the data processing term       for the sake of clarity.</xs:documentation>     </xs:annotation>        </xs:element>         <xs:complexType name="VerbType" abstract="true">      <xs:sequence>          <xs:element ref="TenantID" minOccurs="0"/>      <xs:element ref="AccountingEntityID" minOccurs="0"/>      <xs:element ref="LocationID" minOccurs="0"/>     </xs:sequence>        </xs:complexType>         <xs:complexType name="ActionVerbType">       <xs:complexContent>         <xs:extension base="VerbType">        <xs:sequence>          <xs:element ref="ActionCriteria" minOccurs="0" maxOccurs="unbounded"/>       </xs:sequence>        </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:complexType name="RequestVerbType" abstract="true">     <xs:complexContent>         <xs:extension base="VerbType">        <xs:sequence>          <xs:element ref="Expression" maxOccurs="unbounded"/>       </xs:sequence>        </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:complexType name="ResponseVerbType" abstract="true">     <xs:complexContent>         <xs:extension base="VerbType">        <xs:sequence>          <xs:element ref="OriginalApplicationArea" minOccurs="0"/>        <xs:element ref="ResponseCriteria" minOccurs="0" maxOccurs="unbounded">        </xs:element>        </xs:sequence>        </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:complexType name="ChangeStatusType">       <xs:complexContent>         <xs:extension base="StatusBasisType">       <xs:sequence>          <xs:element ref="StateChange" minOccurs="0" maxOccurs="unbounded"/>        <xs:element ref="UserAreaMeta" minOccurs="0"/>       </xs:sequence>        </xs:extension>        </xs:complexContent>       </xs:complexType>         <xs:element name="ChangeStatus" type="ChangeStatusType"/>    <xs:complexType name="StatusBasisType">       <xs:sequence>          <xs:element ref="Code" minOccurs="0"/>      <xs:element ref="Description" minOccurs="0"/>      <xs:element ref="EffectiveDateTime" minOccurs="0"/>      <xs:element ref="ReasonCode" minOccurs="0"/>      <xs:element ref="Reason" minOccurs="0" maxOccurs="unbounded"/>     </xs:sequence>        </xs:complexType>         <xs:complexType name="StateChangeType">       <xs:sequence>          <xs:element ref="FromStateCode" minOccurs="0"/>      <xs:element ref="ToStateCode" minOccurs="0"/>      <xs:element ref="ChangeDateTime" minOccurs="0"/>      <xs:group ref="FreeFormTextGroup" minOccurs="0"/>      <xs:element ref="UserAreaMeta" minOccurs="0"/>     </xs:sequence>        </xs:complexType>         <xs:element name="StateChange" type="StateChangeType"/>    <xs:group name="FreeFormTextGroup">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Common Free Form Text       elements that occur together.</xs:documentation>     </xs:annotation>         <xs:sequence>          <xs:element ref="Description" minOccurs="0" maxOccurs="unbounded"/>      <xs:element ref="Note" minOccurs="0" maxOccurs="unbounded"/>     </xs:sequence>        </xs:group>         <xs:element name="TenantID" type="MetaIdentifierType"/>    <xs:element name="AccountingEntityID" type="MetaIdentifierType"/>    <xs:element name="LocationID" type="MetaIdentifierType"/>              <xs:complexType name="MetaNoteType">       <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">A free form note. The       lang attribute identifies the language that the note is in. The author identifies       the author of the note. The enrtyDate indicates the date the note was entered or       last modified.</xs:documentation>     </xs:annotation>         <xs:simpleContent>          <xs:extension base="MetaDescriptionType">       <xs:attribute name="use" type="xs:normalizedString" use="optional"/>       <xs:attribute name="author" type="xs:string" use="optional"/>       <xs:attribute name="entryDateTime" type="MetaDateTimeType" use="optional"/>       <xs:attribute name="status" type="xs:string" use="optional"/>      </xs:extension>        </xs:simpleContent>       </xs:complexType>         <xs:element name="Note" type="MetaNoteType"/>               <xs:complexType name="MetaIdentifierType">       <xs:simpleContent>          <xs:extension base="xs:normalizedString">       <xs:attribute name="schemeID" type="xs:normalizedString" use="optional"> </xs:attribute>       <xs:attribute name="schemeName" type="xs:string" use="optional"> </xs:attribute>       <xs:attribute name="schemeAgencyID" type="xs:normalizedString" use="optional"> </xs:attribute>       <xs:attribute name="schemeAgencyName" type="xs:string" use="optional"> </xs:attribute>       <xs:attribute name="schemeVersionID" type="xs:normalizedString" use="optional"> </xs:attribute>       <xs:attribute name="schemeDataURI" type="xs:anyURI" use="optional"> </xs:attribute>       <xs:attribute name="schemeURI" type="xs:anyURI" use="optional"> </xs:attribute>       <xs:attribute name="accountingEntity" type="xs:string" use="optional"/>       <xs:attribute name="location" type="xs:string" use="optional"/>       <xs:attribute name="variationID" type="xs:integer" use="optional"/>       <xs:attribute name="lid" type="xs:anyURI" use="optional"/>      </xs:extension>        </xs:simpleContent>       </xs:complexType>                   <xs:element name="ID" type="MetaIdentifierType"/>               <xs:complexType name="MetaCodeType">       <xs:simpleContent>          <xs:extension base="xs:normalizedString">       <xs:attribute name="listID" type="xs:normalizedString" use="optional"> </xs:attribute>       <xs:attribute name="listAgencyID" type="xs:normalizedString" use="optional"> </xs:attribute>       <xs:attribute name="listAgencyName" type="xs:string" use="optional"> </xs:attribute>       <xs:attribute name="listName" type="xs:string" use="optional"> </xs:attribute>       <xs:attribute name="listVersionID" type="xs:normalizedString" use="optional"> </xs:attribute>       <xs:attribute name="name" type="xs:string" use="optional"> </xs:attribute>       <xs:attribute name="languageID" type="xs:language" use="optional"> </xs:attribute>       <xs:attribute name="listURI" type="xs:anyURI" use="optional"> </xs:attribute>       <xs:attribute name="listSchemeURI" type="xs:anyURI" use="optional"> </xs:attribute>      </xs:extension>        </xs:simpleContent>       </xs:complexType>         <xs:element name="Code" type="MetaCodeType"/>     <xs:element name="FromStateCode" type="MetaCodeType"/>    <xs:element name="ToStateCode" type="MetaCodeType"/>              <xs:complexType name="MetaDescriptionType">      <xs:simpleContent>          <xs:extension base="MetaTextType">        <xs:attribute name="type" type="xs:normalizedString"/>      </xs:extension>        </xs:simpleContent>       </xs:complexType>         <xs:element name="Description" type="MetaDescriptionType"/>              <xs:complexType name="MetaTextType">       <xs:simpleContent>          <xs:extension base="xs:string">        <xs:attribute name="languageID" type="xs:language" use="optional"> </xs:attribute>      </xs:extension>        </xs:simpleContent>       </xs:complexType>         <xs:element name="Reason" type="MetaTextType"/>               <xs:element name="ReasonCode" type="MetaCodeType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Identifies the reason       for an activity</xs:documentation>     </xs:annotation>        </xs:element>                   <xs:simpleType name="MetaDateTimeType">       <xs:annotation>          <xs:documentation xml:lang="en"/>      </xs:annotation>         <xs:union memberTypes="xs:date xs:time xs:dateTime"/>    </xs:simpleType>         <xs:element name="EffectiveDateTime" type="MetaDateTimeType"/>    <xs:element name="ChangeDateTime" type="MetaDateTimeType"/>              <xs:element name="AuthorizationID" type="MetaIdentifierType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Identifyies the       authorization level of the user or application that is sending the Business Object       Document Message. This authorization level being recognized be the receiving system       indicates what can be done on the receiving system(s).</xs:documentation>     </xs:annotation>        </xs:element>                   <xs:simpleType name="ResponseCodeEnumerationType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">The acknowledge values       that OAGi defines for OAGIS. </xs:documentation>     </xs:annotation>         <xs:restriction base="xs:normalizedString">       <xs:enumeration value="Always"/>       <xs:enumeration value="OnError"/>       <xs:enumeration value="Never"/>      </xs:restriction>        </xs:simpleType>         <xs:simpleType name="ResponseCodeContentType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Allows the user to use       any of the codes that OAGi defines or add additional values.</xs:documentation>     </xs:annotation>         <xs:union memberTypes="ResponseCodeEnumerationType xs:normalizedString"/>    </xs:simpleType>                   <xs:complexType name="MetaResponseCodeType">       <xs:simpleContent>          <xs:extension base="ResponseCodeContentType">       <xs:attributeGroup ref="CodeListAttributeGroup"/>      </xs:extension>        </xs:simpleContent>       </xs:complexType>                   <xs:complexType name="ConfirmationResponseCodeType">     <xs:simpleContent>          <xs:extension base="MetaResponseCodeType"/>     </xs:simpleContent>       </xs:complexType>                   <xs:simpleType name="LanguageCodeContentType">      <xs:union memberTypes="xs:normalizedString"/>    </xs:simpleType>                   <xs:simpleType name="SystemEnvironmentCodeEnumerationType">     <xs:restriction base="xs:normalizedString">       <xs:enumeration value="Production"/>      <xs:enumeration value="Test"/>      </xs:restriction>        </xs:simpleType>                   <xs:simpleType name="SystemEnvironmentCodeContentType">     <xs:union memberTypes="SystemEnvironmentCodeEnumerationType xs:normalizedString"/>    </xs:simpleType>                   <xs:simpleType name="ActionCodeEnumerationType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">The action values that       OAGi defines for OAGIS. </xs:documentation>      <xs:documentation>Modified by Infor to add AddOrReplace</xs:documentation>     </xs:annotation>         <xs:restriction base="xs:normalizedString">       <xs:enumeration value="Add"/>       <xs:enumeration value="Change"/>       <xs:enumeration value="Delete"/>       <xs:enumeration value="Replace"/>       <xs:enumeration value="AddOrReplace"/>      <xs:enumeration value="Accepted"/>       <xs:enumeration value="Modified"/>       <xs:enumeration value="Rejected"/>      </xs:restriction>        </xs:simpleType>                   <xs:simpleType name="ResponseActionCodeEnumerationType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">The action values that       OAGi defines for OAGIS. </xs:documentation>     </xs:annotation>         <xs:restriction base="xs:normalizedString">       <xs:enumeration value="Accepted"/>       <xs:enumeration value="Modified"/>       <xs:enumeration value="Rejected"/>      </xs:restriction>        </xs:simpleType>                   <xs:simpleType name="ResponseActionCodeContentType">     <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Allows the user to use       any of the codes that OAGi defines or add additional values.</xs:documentation>     </xs:annotation>         <xs:union memberTypes="ResponseActionCodeEnumerationType xs:normalizedString"/>    </xs:simpleType>                   <xs:simpleType name="ActionCodeContentType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Allows the user to use       any of the codes that OAGi defines or add additional values.</xs:documentation>     </xs:annotation>         <xs:union memberTypes="ActionCodeEnumerationType xs:normalizedString"/>    </xs:simpleType>                   <xs:complexType name="UserAreaMetaType" block="restriction">     <xs:sequence>          <xs:any namespace="##any" processContents="strict" minOccurs="0" maxOccurs="unbounded"/>     </xs:sequence>        </xs:complexType>         <xs:element name="UserAreaMeta" type="UserAreaMetaType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Allows the user of OAGIS       to extend the specification in order to provide additional information that is not       captured in OAGIS.</xs:documentation>      <xs:documentation source="http://schema.infor.com/InforOAGIS/2">This is done by defining       the additional information in XML Schema and referencing the new schema in the xml       instance document throught the use of namespaces. Once this is done the additional       information defined there can be carried in the BOD XML instance       document.</xs:documentation>      <xs:documentation source="http://schema.infor.com/InforOAGIS/2">The Open Applications       Group will make best efforts to quickly consider all proposed submissions.The       UserAreaMeta is always the last element in all components, except where the component       has been extended inline.</xs:documentation>     </xs:annotation>        </xs:element>                   <xs:element name="Type" type="MetaCodeType">      <xs:annotation>          <xs:documentation source="http://schema.infor.com/InforOAGIS/2">Indicates the type of       the object in which assoicated.</xs:documentation>     </xs:annotation>        </xs:element>                   <xs:attributeGroup name="CodeListAttributeGroup">      <xs:attribute name="listID" type="xs:normalizedString" use="optional"> </xs:attribute>     <xs:attribute name="listAgencyID" type="xs:normalizedString" use="optional"> </xs:attribute>     <xs:attribute name="listAgencyName" type="xs:string" use="optional"> </xs:attribute>     <xs:attribute name="listName" type="xs:string" use="optional"> </xs:attribute>     <xs:attribute name="listVersionID" type="xs:normalizedString" use="optional"> </xs:attribute>     <xs:attribute name="name" type="xs:string" use="optional"> </xs:attribute>     <xs:attribute name="languageID" type="LanguageCodeContentType" use="optional"> </xs:attribute>     <xs:attribute name="listURI" type="xs:anyURI" use="optional"> </xs:attribute>     <xs:attribute name="listSchemeURI" type="xs:anyURI" use="optional"> </xs:attribute>    </xs:attributeGroup>                 </xs:schema>        