Dave Degroff said......
There are a couple of issues I'd like to raise with the experience I've had with EDI processors:
1. Would it be possible to enable EDISax to dynamically "discover" delimiters? Here's an example:
ISA*00* 00 ZZ*3327233476332 *ZZ*INTERNAL_TP *010806*1200*U*00401*000000009*0*T:~
In this segment, the only "known" when starting to parse is the segment identifier ("ISA"). The next byte following this identifer becomes the element delimiter for the remainder of the message ("*").
EDI protocol also provides for dynamic discovery of the sub-element delimiter and the segment delimiter. To-wit:
The first element (bytes found between element delimiters following "ISA"), also known as ISA01, has a defined name and purpose. The next element (ISA02) the same, and so on to ISA16. ISA16 has a special purpose – defining the component element separator (in the example - ":").
Furthermore, the byte(s) that immediately follow ISA16 (and preceed the next segment identifier ("GS")) become the segment delimiter. In the example, this is the tilde ("~").
2. In your example, the only repeating elements are "field" and "segment". Would it be possible to include another collection ("loops"), that would include a predetermined group of segments?
3. Speaking of loops, a collection of segments may contain the same segments, but may have different meanings for mapping. For example:
NM1*85*2*PREMIER BILLING SERVICE*****24*587654321
N3*234 SEAWAY ST
N3*2345 OCEAN BLVD
The first collection of NM1, N3 and N4 segments represents one entity ("Billing Provider"). The second collection represents a different entity ("Pay-to Provider"). The means of distinguishing between the two collections is the NM101 element ("85" for "Billing Provider"; "87" for "Pay-to Provider").
Would it be possible to account for conditional content-determining to distinguish between similar objects?