Standards should be based on standards. EDIFACT is based on ASCII and documentation is available from WWW.Premenos.Com as plain text. Well the original contains some PCDOS characters. I took the freedom, to replace them with ASCII in this distribution to improve readability. I don't talk about human readability here. A friend at SAP joked that plain paper is the only platform independent format in that case. But I disliked to retype them. And plain text is more flexible, as I'm a programmer.
Unlike the 0.1 distribution, following distributions will only contain those documents I need to parse by the scripts. Download the 0.1 for a complete set, or surf at Premenos.
As usual. Second versions claim to be better documented and tested, but the truth - they contain more features. So talk about features:
First of all: Its looking like a module. "use strict" and the package concept is a usefull thing. But it'll take a lot of RTFM for me to understand the perl way of doing it. The XML/Edifact.pm doesnt export anything, and its not even neccessary to "perl Makefile.PL; make install".
A 0.2 version is not intendet to become installed, its a test case.
So talk about the test case: Run ./bin/make_test.sh from here, and anything should be fine. Still it need some RTFM for me to understand the perl way of regession test. But the ./bin/make_test.sh is the one this version offers ,-)
I'm now using a tied hash for speeding startup. I've deceided to use SDBM as this DBM comes with any perl, and a small DBM is better in this case.
I've provided a document type definition. And its now possible to use a validating parser like SP from James Clark. You may also notice the renaming from Edi2SGML to XML::Edifact. This namechange reflects that my script is now producing XML and not SGML, and the name should point where in cpan hirachy this package belongs.
You may notice the major change in the DBM design. While the old DBM files had been modeled closely to the batch directory. This version has been partly normalised to improve coding. Its also denormalised for some perlish reasons. Unloading of this DBM into a relational database would be possible with varchars, but the semantics of the 2nd element in segments and composite could only be expressed with some wired object relational databases like PostgreSQL.
Also the DTD changed for namespace reason. The 0.2 need to add the word literal, where element names clashed segment names of the standard. And it droped the composite informations. Now trsd:party.name means the segment, while tred:party.name points to the element.
This allows to parse the XML message to produce a EDI message without an backtracking parser. The event based parser used for xml2edi is quite new, and certainly contain some bugs. Please dig around your real life messages, translate them with edi2xml, back with xml2edi and compare the original with the double translation. I've tried a robust solution, that doesnt croak with codes from the unknown namespace, I hope.
Version 0.30 and 0.31 used edicooked:message as namespace, versions 0.32 and up will use edifact:message for the main namespace. The technical reason is quite simple. The namespace prefix of a message does not mean anything. Its only a shorthand for the provided URI in the xmlns attribute. So any distinct XML message can claim to be in the edifact: namespace, if the URI is distinct. So if other projects starts becoming implemented, they can claim to be in the edifact: namespace for the same right.
Version 0.33 first of all solves a bug shown up with xml2edi and a TeleOrdering message translated by edi2xml. I just did forgot to encode less than and ampersand, if they occure as translation in a code list. So NAD+OB+0091987:160:16' will now translated using Dun & Bradstreet, which is right.
Two other improvements are for major notice. The brand new Perl5
version 005.60 contains a profiler, and hunting the hot spots and
optimising the SDBM by further denormalisation improved performance
of edi2xml
by factor 12. I hope nobody did use the SDBM internals
so far. The last major improvement is, that I'm getting familar with
ExtUtils::MakeMaker, File::Spec and friends. This 0.33 version is the
first that does install - at least on my Linux box :-)
A last note about change of 0.2 to 0.30. Treat this number as 0.3.0 translated to perl canon. The 0.3 is not finished, coming versions claiming to be any 0.3x will be step stones to what I think the 30% XML::Edifact solution should contain.