EDIFACT Support validation of empty segments

[benisantos]

In transaction schema, if we put:

<segmentType name="SRC" />

an error occurs parsing the schema: io.xlate.edi.internal.schema.StaEDISchemaReadException: Unexpected XML event [2]

And if we put:

<segmentType name="SRC">
  <sequence />
</segmentType>

an event ELEMENT_OCCURRENCE_ERROR is returned by EDIStreamReader::next with error type TOO_MANY_DATA_ELEMENTS.

This issue is related to #10

[MikeEdgar]

@benisantos, thanks for the report. I'll be looking into this shortly.

[MikeEdgar]

@benisantos - when the TOO_MANY_DATA_ELEMENTS error occurs, can you confirm that the segment involved is the SRC?

[MikeEdgar]

After doing some additional research on this issue, I believe that your configuration that includes the following schema type should work. At this point, I suspect that there is some other data error in the input file you are processing that is causing the ELEMENT_OCCURRENCE_ERROR.

<segmentType name="SRC">
  <sequence />
</segmentType>

[benisantos]

Hi @MikeEdgar and thank you for your time. I attach a simple test with the TOO_MANY_DATA_ELEMENTS failure.

validation-test.zip

The test fails with: java.lang.AssertionError: ELEMENT_OCCURRENCE_ERROR: TOO_MANY_DATA_ELEMENTS (seg=SRC, elemPos=1, compoPos=-1, textOnError=null)

[MikeEdgar]

@benisantos , thank you for the example. I will be providing a fix for the issues you flagged with TODO comments as well in your test case related to the UNA segment.

[MikeEdgar]

@benisantos, the reason you are seeing an issue with the validation of the IATA in UNB element 1, component 1 and PNRGOV in the UNH is because the internal control schema is based on the ISO control segments which do not include those values. Are you aware of any publications by IATA that would define the valid values for IATA's message types?

The use of IATA in the UNB seems to be in conflict with the guidelines here (https://www.gefeg.com/jswg/cl/v4x/40200/cl1.htm), but I understand that the PDF linked in #10 requires that code value and it should be supported somehow.

[benisantos]

@MikeEdgar "Are you aware of any publications by IATA that would define the valid values for IATA's message types?"

• No, sorry. I'm only aware of "PNRGOV" and "ACKRES" msg types :(

[MikeEdgar]

@benisantos , the following code sample is a way you might be able to "ignore" the code values in the UNB and UNH segments. You could alternatively use an EDIStreamFilter to ignore them and keep your main logic cleaner. I have identified the issues with TOO_MANY_DATA_ELEMENTS and SEGMENT_NOT_IN_DEFINED_TRANSACTION_SET for UNA and will have a new release published soon, hopefully today.

case ELEMENT_DATA_ERROR:
    // TODO Change "control schema", because it does not recognise "IATA" (UNB), "PNRGOV:11" (UNH)
    if ("DE0001".equals(reader.getReferenceCode()) && "IATA".equals(reader.getText())) {
        break;
    }
    if ("DE0065".equals(reader.getReferenceCode()) && "PNRGOV".equals(reader.getText())) {
        break;
    }
    if ("DE0052".equals(reader.getReferenceCode())) {
        break;
    }
    // Handle the error

[MikeEdgar]

@benisantos - the fix for the two issues here has been release and is now available in version 1.4.0.

<dependency>
  <groupId>io.xlate</groupId>
  <artifactId>staedi</artifactId>
  <version>1.4.0</version>
</dependency>

[benisantos]

Thank you so much @MikeEdgar