doc/approaches.txt
Schema Walking & Callbacks
-----------------------------------------------------------------------------
Like the 4010 EDI Generation code, where the transaction set definition is
iterated and some dispatch method is called to render each segment as its
visited.
Upsides:
- Reordering sibling nodes requires only changing the definition, and not the
client code.
- Validation is simple, because we can compare the current segment definition
to the return value of the callback at each point.
Downsides:
- While the iteration is performed from the transaction set itself, the client
code needs to control the iteration to some extent, based on the appropriate
number of loop iterations.
- It's awkward for the callback must maintain state across multiple invocations.
There are no "closing tags" with EDI and the client code doesn't know when
items in the state can be discarded.
- Validating the maximum number of loop iterations is also awkward. Should the
number of calls be limited, potentially truncating loop iterations without
the client knowing? Should we allow the callback to be called one more time,
tempting the client code to violate the standard?
Unrestricted
-----------------------------------------------------------------------------
The client code generates the full X12 transaction as a string, without any
guidance from the transaction set definition.
Upsides:
- It's simple to implement. The client code has full control of iterating the
objects that need to be serialized (claims, claim lines, eg).
Downsides:
- Validation can happen only when the generation is complete, meaning there is
no way to tell which part of the code (eg stacktrace) created invalid output
without walking through the code base.
- Without significant effort, code written to concatenate strings based on all
kinds of conditions can become very unreadable. Using a DSL would probably
alleviate readability problems.
Incremental Parse Tree
-----------------------------------------------------------------------------
The client code *incrementally* generates the X12, yielding it to a parser
which incrementally builds the syntax tree. Alternatively, the client calls a
DSL which is a state machine, which builds the AST
Upsides:
- Validation happens as the X12 data is being generated, and invalid X12 can
be tagged with a stack trace, cause an exception, etc.
- Constructing the parse tree is less costly, as its being built directly from
the DSL instead of being reconstituted from the serialized string.
- The client code retains control flow, avoiding the awkwardness of callbacks
and event-driven X12 generation.
Downsides:
- Difficult to implement the state machine