One simple yet powerful way to make most existing XQuery and XSLT engines able to process EDI as XML is to make the processor able to access non-XML data through custom URI resolvers. What is a URI resolver? When an application tries to access a resource referenced as, for example, file:///c:/myFolder/myDocument.xml or http://myServer/myFolder/myDocument.xml, what happens under the cover is that the standard URI resolver understands that “file:” identifies a resource on your local file system and retrieves the file myDocument.xml in the myFolder directory, or “http:” identifies a request to access a resource through the HTTP protocol and it connects to myServer to GET myfolder/myDocument.xml.

That mechanism is extensible. You can, for example, create and use a custom URI resolver that knows how to deal with a specific URI scheme. For example, if your application references a URI, such as converter:EDI?file:///c:/myMessage.edi, the custom URI resolver will know that what the application is requesting is to retrieve an XML interpretation of the EDI message myMessage.edi.

That’s quite a powerful mechanism; applications can leverage it to do what we described above: give XQuery or XSLT processors the ability to handle both XML and non-XML data transparently as if everything was in fact XML.

For example, an XQuery could be in charge of retrieving all the book orders received as part of an incoming EDI message from a business partner and return them in an XML format required by your application. Assume the EDI incoming message looks like Listing 1 and that the XQuery processing the EDI message looks like Listing 2. The result of such XQuery would be something like Listing 3.

As you can see, the XQuery doesn’t know about the fact that you’re querying an EDI message to generate XML. From the XQuery point of view, you’re dealing strictly with XML.

A similar extension can apply on the output side. Suppose I want to answer my business partner using an EDI message (since that’s all that partner can process); of course I’d like to be able to just deal with the generation of the proper response in XML terms, and then assume that what the business partner gets is actually EDI.

You can do that, for example, by extending the concept of output method. Both XQuery and XSLT already support the ability to instruct the processor to serialize the result of their processing not only as XML, but also as HTML, XHTML, or event text. What if you were able to tell your XQuery processor: “serialize the result as EDI?” Your application would be able to focus on the fact that it’s dealing with querying and creating XML, but its result would in fact be EDI.

For example, the XQuery in Listing 4 (where only a portion is displayed) would generate an EDI message as the result as shown in Listing 5.

Conclusion
Even if XML is becoming more and more widespread, modern B2B applications still need to deal with a variety of formats for incoming and outgoing messages. EDI is still widely used, especially in some specific market verticals, and it seems unlikely that its use will vanish any time soon. Being able to have infrastructures that can deal with heterogeneous data formats without forcing IT organizations to worry about what such data formats are and how to deal with them is crucial. Languages like XQuery and XSLT that are meant to work against the XML Data Model provide a great way for abstracting the physical details of the data that has to be manipulated or created and focus only on handling XML data. That approach allows EDI, text, or binary formats to be queried or even generated as if they were plain XML. There are already XQuery implementations on the market that expose such functionality and that even extend that approach to the relational world, making it possible to deal with relational data, XML, and non-XML documents as if they were all expressed as an XML Data Model.