Thank you for sharing that with all of us.
I could have said "multipass preprocessor" but then many might have thought,
"Oh, I know what those are." and remained dim.
I attempted to report details of a real world example of using EDI "specs"
structure as well as the data of any particular transaction document to
create dB records for "preprocessor template sets" so a "driver" could be fed
a single value, from whence record sets from the dB would be overlayed on
said templates, producing (mucho) source code (pronto); and that
a. such "types" of activity could be applied sequentially and or parallel
to do many things (get lots of work done in microseconds), deferring actions
until run times, even
b. not needing to "care" about which "set" of specs for which document
type were at hand at any particular moment, demonstrated one solution to
version control that could be especially germane to small groups needing the
effects of thorough management of lots of code with lots of changes
c. XML might be too much a platefull to use for work already done in EDI,
but that XML is definitely needed for such work to go further
d. that a dB data-dictionary's validations and indexing, especially for
enforcing logic conditions (like uniqueness) at record creation "time", seem
underutilized as coding tools
e. there are some simple short sniglets of code that, via preprocessing
of templates from dB records, dB data-dictionary records especially, can
(auto)populate generated source code with the feature of having such
validations etc. placed in the source code, thus applied at runtime e.g.
EDI-997 ACKs manufactured and transmitted in the same session the documents
they ACKed are "picked up" in, no latency or call-back, thus "holding" such
document images longer than first p/u can be a huge set of records for
companies like Ford Motor Co. ( They can just be auto-regenerated iff.
actually requested; the space, the resources, freed up both in hardware and
"helpware"/"supportware"? )
f. not only is such auto-generated code "consistent" to the point of
being much more self-documenting, but that some of the dB records, "melded"
with the data input meant for some templates can straightforwardly
auto-generate documentation at the (same) time of code generation, with a
concurency, let alone "accuracy" that is pretty cool (never printing ANY
documentation, or part/screenfull of, until it was likely someone was
actually going to read it, at which time it is way up to date and IS the
"spitting image" of the ACTUAL SOURCE CODE THAT WOULD/DID RUN AT THAT MOMENT).
Sorry, I got excited about it again.
Then I mentioned my attempts to "represent" coding language specs (modified
Bakus-Naur form, actually) in dB records also, using the straight forward
ease of dB indexing and validating features to more easily construct a
compiler-compiler that, upon editing/updating such records, I could
auto-FOOF! a completely new compiler, parser, whatever, "on the fly", to use
with all the above, thus implementing EDI and then XML as the (not so)
"little language", a "method" of programming referred to in early compiler
writing papers I became familiar with. That such methods simulate "real
time" on many newer and faster systems, new solutions to complex
binding/run-time, storage and latency problems seem worthy of further
investigation.
Regards,
Jim Cunningham
P.S.
If my reference to Satan causes you the trepidation you did relate, thank you
for demonstrating the point I attempted to make.
:)
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
