XML::Edifact - an approach towards XML/EDI as a prototype in perl: Roadmap

Previous Next Table of Contents

## 5. Roadmap

I'm using even and odd numbering to distinct from stable and experimental version. Well this 0.2 was not as stable as an even number suggests. And I hope this 0.3x is stable enough as as often a third version, will be the first usefull one.

Be warned: Anythink here is pure vaporware. I'm writing XML::Edifact in my spare time, and I hope to complete one version per month.

0.3x

  This version is under development: It should integrate better into the XML::Parser environment, and use some XML::Parser to translate XML::Edifact-0.3x messages back into UN/EDIFACT. Only even numbers 0.302468 can be cound on CPAN. Odd versions are published by eMail only. As a warning different 0.31 exist. Some eMail's I got, caused imediate code changes and a reply to test them. If you receive a 0.3-9 13579 file by eMail: Do not distribute it widely, those versions are internal only.

0.4x

  This version will focus on portability. While Perl ensures portability across the unix'es, MacOS and Win32 will cause some problems. The 0.4 version will also be the first one intended to become installed. As installation also means configuration of non Perlish paths e.g. for webserver, mime.types, mailcap, dtds and databases, XML::Config.pm will be discussed in the perlxml list.

0.5x

  The next important step will be a reverse engineering of the document type definition of the original EDI standard draft. This version will provide segment groups for defined document types like orders and invoices. Most important will be the introduction of a XML format for defining code list extensions. This format will probately some RDF.

0.6x

  Stabilisation by disscussion and consens about the XML DTDs introduced with 0.5.

0.7x

  EdiCooked is far from being KISS. This release will try on a smarter DTD called EdiLean. EdiLean will focus on PRICAT, ORDERS, ORDRSP, ORDCHG and INVOICE. If a consens about a KISS XML/EDI already exist, EdiLean will try to implement it.

0.8x

  Stabilisation by disscussion and consens about the XML DTDs introduced with 0.7.

0.9x

  Its important for me that authentication and authorisation will be provided `before` I call it final 1.0. Some Edifact messages contain medical informations (MED*), other contain personal informations (JOB*). Most messages contain viable information for running a bussiness. Only cryptography on a document level would preserve authentication and authorisation once a message stored on a disk.

  Alf O. Watt ( alfwatt@pacbell.net ) proposed a simple solution using namespaces and processing instructions at the perlxml mailing list in December 1998. The beauty of this aproach is, that the secure document is still wellformed and valid of the same document type. It could even translated back to UN/EDIFACT to obtain a message with crypted segments.

1.0

  I hope that any consens have been found on that road, so the DTDs wont change in further releases. Those versions may focus on `using` XML::Edifact in real life applications. I can think about an SQL interface, a Cobol interface, a message designer, a DOM/CORBA wrapper, and much more.

  Once I think to have XML::Edifact complete, I have to think about speed. Perl is a perfect language for prototyping, but profiling and using a low level language like C for hot spots, will be necessary to handle large batches.

Previous Next Table of Contents