Navigation of sibling detail tables is wrong

[kputnam]

In transactions that have multiple detail tables, m.find behaves incorrectly when iterating their start segments. This happens under very specific circumstances. Consider this 277 Health Care Information Status Notification transaction where the HL segments denote the start of a loop (and possibly a table).

HL*..*..*19
HL*..*..*19

When building the parse tree, a heuristic is used: the segment is placed within the current structure if possible, but a new "uncle" structure is created only if the current structure cannot be used. For example, if two HL*..*..*19 occur consecutively, they will be placed in adjacent loops within the same table.

TableVal[Table 2 - Service Provider Level](
  LoopVal[2000C SERVICE PROVIDER LEVEL](
    SegmentVal[HL: Service Provider Level](
      AN.value[ E628: Hierarchical ID Number](3),
      AN.value[ E734: Hierarchical Parent ID Number](2),
      ID.value[ E735: Hierarchical Level Code](19: Provider of Service),
      ...
    ...
  LoopVal[2000C SERVICE PROVIDER LEVEL](
    SegmentVal[HL: Service Provider Level](
      AN.value[ E628: Hierarchical ID Number](5),
      AN.value[ E734: Hierarchical Parent ID Number](2),
      ID.value[ E735: Hierarchical Level Code](19: Provider of Service),
      ...
    ...

However, if an HL*..*..*20 is placed between them, each HL segment must be placed in separate tables.

TableVal[Table 2 - Service Provider Level](
  LoopVal[2000C SERVICE PROVIDER LEVEL](
    SegmentVal[HL: Service Provider Level](
      AN.value[ E628: Hierarchical ID Number](3),
      AN.value[ E734: Hierarchical Parent ID Number](2),
      ID.value[ E735: Hierarchical Level Code](19: Provider of Service),
      ...
    ...

TableVal[Table 2 - Information Source Level](
  LoopVal[2000A INFORMATION SOURCE LEVEL](
    SegmentVal[HL: Information Source Level](
      AN.value[ E628: Hierarchical ID Number](1),
      AN.empty[ E734: Hierarchical Parent ID Number],
      ID.value[ E735: Hierarchical Level Code](20: Information Source),
      ...
    ...

TableVal[Table 2 - Service Provider Level](
  LoopVal[2000C SERVICE PROVIDER LEVEL](
    SegmentVal[HL: Service Provider Level](
      AN.value[ E628: Hierarchical ID Number](5),
      AN.value[ E734: Hierarchical Parent ID Number](2),
      ID.value[ E735: Hierarchical Level Code](19: Provider of Service),
      ...
    ...

This is a reasonable heuristic for constructing the parse tree. However, the same heuristic is used when traversing the parse tree. If we're currently positioned at an HL*..*..*19 and we call m.find(:HL, nil, nil, "19"), the search is incorrectly limited to within the current loop. In the example above, we cannot reach the third HL segment because it was placed in an "uncle" table, which is outside the scope of our search.

Note that we can reach all HL segments by removing the element constraints: m.find(:HL) should first search for sibling loops within the current table, then search uncle tables. This was addressed in #6.

[kputnam]

This change required care to point out specifications that may be parsed unexpectedly. Detail tables are, by definition, always repeatable. New occurrences of the table's entry point (e.g., an HL segment or a 2000 loop) will now always create new table instances instead of potentially being nested inside the current table.

As a result, even if the table's entry point is marked repeatable, it will never be parsed such that it occurs consecutively -- because it will be placed in a separate table. Now TableDef checks for this potentially unexpected circumstance and throws an exception on construction. If you have something like

TableDef.detail("Table 2 - Detail",
  d::LoopDef.build("Loop 2000 - Detail",
    d::RepeatCount.unbounded(1)),
    ...

You will need to change the repeat count to bounded(1). The included HIPAA transaction sets and guides have already been fixed.