Abstract Data Type (ADT)
is a mechanism provided by Extensible Markup Language (XML) schemas to enforce substitution for a specific element type. When an element or type is declared as “abstract,” it cannot be directly used in an instance document. Instead, a member of the element’s substitution group must be present in the instance document.
ADTs play a crucial role in Electronic Data Interchange (EDI) systems, which facilitate the exchange of structured business documents between different organizations. In the context of EDI, ADTs ensure standardization and interoperability by defining a set of abstract elements that serve as placeholders for specific data elements.
One practical use case of ADTs in EDI is in the exchange of purchase orders. Organizations often have different internal formats for their purchase order documents. However, to enable seamless communication and integration between trading partners, they need to conform to a common standard. ADTs allow organizations to define abstract elements for various components of a purchase order, such as buyer information, supplier details, and item descriptions.
When an organization sends a purchase order in its internal format, it needs to map the data to the corresponding abstract elements defined in the common EDI schema. This mapping ensures that the purchase order document adheres to the agreed-upon structure and can be correctly interpreted by the recipient’s system. By enforcing the use of abstract elements and their substitution groups, ADTs ensure consistency and compatibility in the exchange of purchase orders and other EDI documents.
In summary, ADTs provided by XML schemas are valuable tools in the EDI domain. They enable organizations to define abstract elements and enforce the use of appropriate substitutions, ensuring consistent data exchange and interoperability between trading partners.
XML Example
<!– Author: EDIconnect –>
<xs:element name=”Product” type=”AbstractProduct”/>
<xs:complexType name=”AbstractProduct” abstract=”true”/>
<xs:complexType name=”FoodProduct”>
<!– Definition of FoodProduct structure –>
</xs:complexType>
<xs:complexType name=”ElectronicProduct”>
<!– Definition of ElectronicProduct structure –>
</xs:complexType>
<xs:complexType name=”ClothingProduct”>
<!– Definition of ClothingProduct structure –>
</xs:complexType>
EDIfact Example
UNH+1+INVOIC:D:93A:UN:EAN008′
BGM+380+1234567890+9′
DTM+137:20230630:102′
RFF+ON:12345′
NAD+BY+123456789::9′
NAD+SU+987654321::9′
LIN+1++1234567890:EN’
IMD+F+:::Product description’
QTY+47:100′
MOA+203:1000.00′
UNS+S’
UNT+10+1′
— Author: EDIconnect
iDoc Example
UNH+1+INVOIC:D:93A:UN:EAN008′
BGM+380+1234567890+9′
DTM+137:20230630:102′
RFF+ON:12345′
NAD+BY+123456789::9′
NAD+SU+987654321::9′
LIN+1++1234567890:EN’
IMD+F+:::Product description’
QTY+47:100′
MOA+203:1000.00′
UNS+S’
UNT+10+1′
— Author: EDIconnect