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

Next Previous Contents

## 5. Roadmap

I'm using even and odd numbering to distinct from stable and experimental version. Well 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.

Both 0.4x track and 0.5x track are active currently. The 0.35 was quite stable, and there is a need for portability, while the version under development is far from beeing usable.

0.4x

  This version focus on portability, of the EdiCooked style.

  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

  This is the unstable version track.

  XML::Edifact now provides PerlSAX objects as drivers and handlers to UN/EDIFACT, making usage more flexible. Current step is the reverse engineering of a document type definition for the original EDI standard draft.

0.6x

  Stabilisation by disscussion and consens about features introduced with 0.5. Portability across networks using SAX may be one concern.

0.7x

  EdiCooked is far from being KISS. This release will try on a smarter DTD called EdiLean. EdiLean will focus on PRICAT, QUOTES, 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.

Next Previous Contents