X12 - Segment ISA - Component element separator

[spointeau]

Hi,

I am puzzled because the ISA "component element separator" cannot be read (at positiion 16)

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *230912*1312*U*00401*000000001*0*T*>~

    [EdiValue("X(1)", Path = "ISA/15", Description = "ISA16 - Component Element Separator")]
    public string ISA_16_ComponentSeparator { get; set; }

The value is just null.

However, by implementing the interface IEdiGrammar, it works if the function IsSpecial does not take care of the ComponentDataElementSeparator.

    public bool IsSpecial(char character)
    {
        return character == SegmentNameDelimiter
               //|| character == ComponentDataElementSeparator
               || character == DataElementSeparator
               || character == SegmentTerminator;
    }

Please could you help me to understand ? Is it a parser issue ?

Additionally, we are specifying the ComponentDataElementSeparator in the grammar instead reading it from the file. I am not sure if this is critical, but could be potentially annoying I suppose. (see #244)

Thank you for your library and many thanks in advance for your answer.

[cleftheris]

The abstraction does not handle well the case of the X12 EDI format in terms of discovering the grammar by inspecting the first line (it was based on EDI Fact where it is simper).
The way it works now is in order to read and bind the first line because it also contains data itsef is by knowing the grammar upfront (delimiters etc.).

What needs to change:

1. I should be reading the first element ISA since it is of fixed length 106 characters
2. Figure out the delimiters from their fixed positions and update the grammar.
3. and then move the position of the stream to the beginning in order to start reading binding/deserializing.

The above also means that in the case of X12 either the grammar or the Stream reader should contain logic specific to X12 and not only relying of IGrammar as a configuration object.

While this is not such a difficult task, it is tricky without introducing bloat. Also I have not found the time to update the codebase in quite some time.
Since the above process is not compatible to the way the EDIFact figures out the grammar at the moment so we must make changes by not breaking the expected behavior there.

If it is something you are up then fell free to make a pull request and I will try to check it out.

PS: As for the second question the delimiter is special since it is considered to be the "bounds" and not the "data" inside a component so it is escaped when read. This is the reason I describe that there is the need of custom logic for the case of X12

[spointeau]

OK I understand.

I am currently not at a level where I can contribute, I am still discovering the EDI format, and I am currently making the EDI 940 and 943 object models. (note: It not so easy to make reusable segment object through different document type)

I will definitely try to contribute back later, once I really understand everything.