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.30 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.

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.

1.0

I hope that any consens have been found on that road, so the DTDs wont change in further releases. Those 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.


Previous Next Table of Contents