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