Non-deterministic state about stupidedi HOT 4 CLOSED

Hi Isi,

This can happen when there's more than one way to parse the input. It could be an issue with the grammar, or possibly an important element is missing from the input.

For instance, many grammars have different NM1 loops which are instantiated by the parser depending on one of the elements -- like NM1*XX might be "Customer Name" and NM1*YY might be "Supplier Name". If your grammar accidentally specifies XX as an allowed value for both loops, then the parser constructs two trees: one where the segment means "Customer Name" and another tree where the segment means "Supplier Name".

On the other hand, suppose your grammar is not ambiguous. If the input doesn't have a value at all in the first NM1 element (it's just blank), the parser doesn't have enough information to decide, resulting in the same problem. The parser could throw away the input (and create InvalidSegmentVal nodes), but the hope is that further input will resolve the ambiguity, which doesn't always work.

You can debug this by printing each parse tree (hopefully there are only a few) and comparing them -- ideally you have a small number of trees, and only one of the parse trees is correct, and you can decide by looking at it. To print the parse trees, you can pass a -N flag to edi-pp. This was just pushed to master, so be sure to pull these changes into your working branch. If the trees are large, I would dump the output of edi-pp -N to a file and use a diff tool to help find the first place where they diverge.

Once you find the location where they diverge, look back at your grammar to see if you have overlapping constraints (like both segments share allowed values, but they should've been disjoint) or perhaps constraints are missing (like you have two reachable NM1 segments but no constraints on allowed values). The implementation guide builder should be doing the work of catching ambiguous grammars, but it's not implemented, and even that wouldn't catch all the potential problems.

from stupidedi.

Hi Kyle,

Adding this flag to edi-pp is really helpful

For one of the sample files it never stops processing, no return, but luckily I got other files which process even though the output is very lenghty

from stupidedi.

One of the segments did not have a ending marker ~

i.e:

LIN**BP*999J16F000*ON*987654321~
SN1**10*PC
HL*4*2*I*0~

noticed SN1 does not have a line termination marker, that was causing the non-deterministic problems.

Now, by having a proper of SN1 shouldn't it have handle this error ? basically the system was reading PCHL as one item yet the last SN1 field (E355) is defined as max 2 chars-- just asking to see if we can improve StupidEDI

from stupidedi.

I have been studying the trees generated by edi-pp -N and strangely enough some of the trees do not show any errors, are identical to each other

I will refresh git w/ the latest need to take a break as I am not being productive (spent most of the day chasing these issues down w/o any luck) 👎

from stupidedi.