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.
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.3
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.
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.
Stabilisation by disscussion and consens about the XML DTDs introduced with 0.5.
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.
Stabilisation by disscussion and consens about the XML DTDs introduced with 0.7.
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.
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.