EDI is a collection of message transmission formats used primarily in electronic business-to-business (B2B) transactions where the implementation pre-dates the use of an XML-based format.

EDI specifications exist for a whole range of transactions, most covering those needed to implement ERP in association with suppliers.

• libedi aims to be as generic and flexible as possible, because each of the main EDI variants in widespread usage (EDIFACT, TRADACOMS, ANSI ASC X12, ODETTE) have different syntax rules.

• libedi does not concern itself with the transmission or reception of EDI interchanges themselves, simply with parsing them into an easily-digestible form, or generating them programatically.

• At present, libedi only performs a “low level” parse of an interchange: the result is a structure containing one or more segments, each containing one or more data elements (of which the first is treated as the segment's tag), in the order that they appear in the message. No attempt at present is made to produce a higher-level representation of the interchange based upon knowledge of the EDI variant in use. For example, libedi doesn't know that an UN/EDIFACT message is wrapped with UNB…UNZ segments, or that a functional group is wrapped with UNG…UNE segments. As far as libedi is concerned, there's simply a UNB segment, followed by a UNG segment, (followed by a UNH segment and so on), and then a UNT segment, a UNE segment, and finally a UNZ segment. This is likely to change in the future, however.

• libedi contains no support itself for reading and writing XML-based representations of EDI interchanges, but can be used to facilitate the development of software which does. Given the level at which libedi operates, it's unlikely that the addition of this as a feature would be useful currently: any representation produced by libedi would simply be the same segment and tag structure encapsulated within XML nodes, when what would generally be required would be an XML representation of the information contained within the interchange, structured in a way most suited to the type of information being represented (that is, for example. a purchase order would have a different XML document structure to a flight availability enquiry).

• It's conceivably possible to extend libedi such that it has support for (and knowledge of) specific EDI interchange types, but this can only be accomplished if the relevant format and structure information can be expressed in a generic and extensible manner (for example, something not dissimilar to XML Schema Definitions).