Complex Elements
Complex QDoc elements containing other elements, representing business data entities in QAD Enterprise Applications, map to iterating frames in the case of the UI APIs and temp-tables in the case of service interface and QAD JIT Sequencing APIs. Their names are natural business terms expressed in camel-case with no database-specific notation (for example, pt_mstr for item) or special prefixes/suffixes. For elements that are associated with temp-table parameters in the service interface and QAD JIT Sequencing API methods, the QDoc element name is identical to the temp-table name but without the tt prefix and with the first letter changed to lower-case. For example, the temp-table ttPurchaseOrderDet in the maintainPurchaseOrder API method would be expressed as purchaseOrderDet in the QDocs.Just as the service interface and QAD JIT Sequencing API temp-tables make heavy use of common field lists (for example, the include files mfaittxt.i, mfctit01.i, and so on), so do their corresponding QDoc elements. XML schema supports an inheritance mechanism whereby types can be derived by extending other types by adding fields, analogous to subclassing in object-oriented programming languages. Using this technique, an abstract base type ApiTempTableType is defined that includes all the fields common to all service interface and QAD JIT Sequencing API temp-tables. Reusable derived types such as TransCommentType are built from ApiTempTableType by extension, and in turn used to build more specific types such as PurchaseOrderCmtType. The type hierarchy is built by inspecting the present service interface and QAD JIT Sequencing API temp-table definitions and common field lists. The collections of common data are modeled as base types in the XML schema.The following XML schema definition fragment is for the ApiTempTableType, as well as fragments of the TransCommentType, PurchaseOrderCmtType, and OperationType definitions. The ApiTempTableType definition is stored in the XML schema file for common QAD Enterprise Applications QDoc objects, while the derived types are stored in separate schema files. See QDoc Namespaces.<complexType name="ApiTempTableType" abstract="true">
<sequence>
<!-- Common API temp-table fields from mfaittxt.i -->
<element name="apiSequence" type="string"/>
<element name="apiSuccess" type="boolean"/>
<element name="apiExternalKey" type="string"/>
</sequence>
</complexType>
<simpleType name="OperationType">
<restriction base="string">
<!-- Common Operation values from mfaiocon.i -->
<enumeration value="A"/> <!-- Add -->
<enumeration value="M"/> <!-- Modify -->
<enumeration value="R"/> <!-- Remove -->
<enumeration value="U"/> <!-- Unmodified -->
<enumeration value="S"/> <!-- Sync -->
<enumeration value="G"/> <!-- Get -->
<enumeration value="N"/> <!-- No-op -->
</restriction>
</simpleType>
<complexType name="TransCommentType">
<complexContent>
<extension base="qdoc:ApiTempTableType">
<sequence>
<!-- Common Transaction Comment temp-table fields
from mfctit01.i, mfctid01.i -->
<element name="operation" type="qdoc:OperationType"
minOccurs="0"/>
<element name="seq" type="int" minOccurs="0"/>
<element name="ref" type="string" minOccurs="0"/>
<element name="type" type="string" minOccurs="0"/>
<element name="lang" type="string" minOccurs="0"/>
...
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="PurchaseOrderCmtType">
<complexContent>
<!-- No P.O.-specific fields to add to base Transaction
Comments, but the type is still required in order
to map easily to the corresponding API temp-table. -->
<extension base="qdoc:TransCommentType"/>
</complexContent>
</complexType>
Note: QDoc schemas in the 1.1 standard use a flat structure—there is no superschema.