Claiming, humbly, to have substantial experience with EDI implementation and
issues et. al., I found XML et. al. "very interesting", even exciting. "My"
EDI "system" could not overcome the drudgery of output beautification
automation. Yet, with the broad utility of EDI, I find XML useful only for
"rendering" data back to the beautifully crafted printed-form paper document
images that "market" the presenter so effectively, when done well. And I do
see substantial utility for "data mining" due to there being some real and
potentially unlimited "depth" of additional data about data (which EDI could
"tack on" w/o any bother to me, but that would be such a revision; might as
well do that AND EDI in XML). The work embodied in EDI does not need to be
done "over" or again; the world does not need, yet another, Accounts
Receivable Package.
How so?
I, with the help of my son, whom I had just begun employing/"teaching" data
processing practice, as he had wasted a year's college full scholarship
tuition on (advanced placement!) life-sciences, "manufactured" an EDI product
suite to download Ford Motor Co. POs w/ACKs in 89 days, as I was given 90.
My family business was by far the smallest of 100 prox. vendors invited to
participate in Ford's launching of it's EDI commitment. I made every
instance of everything extensible, on my guess that more would be asked. In
my translator, I left "hooks"/tokens for everything, since the EDI element
nomenclature had purposely made "label" context-unique and had thus
trivialized everything IMHO. Thus, pipelining all EDI data into a "full" set
of fully normalized dB records/fields, processing was just recursive looping
lookup-act. In fact, hard copy, reports etc. were then, all wonderfully easy
to implement and modify. When charged to "do" all the other EDI documents,
mimicking the normalized purchase-order/internal-order (substantial "symmetry
there, huh?) records structure, I realized I should now first create a fully
normalized set of records of EDI data about EDI data. Then, cascaded select
loops could take as little as an order# or PO#, to be fed to a preprocessor
to overlay the key points in a template select-cascade routine that was
ordered by the EDI nomenclature's structure. Everything I was asked to
deliver from thereon seemed easy, always pausing to make new "general" forms
of select/print/etc. cascades, bearing tokens at all key points for the
preprocessor to overlay any specific data to be processed by the structure of
the general code in the template (adding additional EDI spec. documents only
required new record sets in the normalized EDI record structures; structured
records "about" EDI structure, according to the specs.); which when the
specs. changed, only required an additional new "master" record of what EDI
segments/elements/etc. were to be implemented over all EDI documents to be
"collected" into this new subset; with a native key index of sets of sets,
version#, simply listing the affected EDI structure items affected by the
change, the new structure was easily imposed on the cascade of affected
structures. All prior work was immune to change issues bc. all such work was
made very strictly as general as possible, to implement parameter driven code
generation by preprocessor cascading to totally rewrite ALL pertinent code
upon hitting the "FOOF! button". Point being, after the "appropriate" record
structures were created with code routines to populate them, ALL EDI specs.
were "populated into" those structures, including the structures (per trading
partner specs. sets, etc.) that "represented the sub-sets of all EDI
structures that partner wanted to deal with. Thus, partner "master"
records/lists-of-lists of what they wanted to end up with at their end,
pulled everything together for use with/by that partner. (I think that all
may seem "runny" at the moment, you can just pull the plug now, if you feel
the urge. I am trying to get this out while I'm supposed to be doing
something else. I'm not going to be able to clean it up) All this was
possible bc. I had crafted a "browser generator" that took any dB record
filename, examined all indexes for all "true children/parents" of that
record; its full lineage; and cascaded thru the code that generated the
"connected"/"inter-callable" programs to generate the browser for each and
all those records (making each/any-possible parnet/child record
displayable/creatable/updatable at the point in time the update cursor in any
of same landed on such a field. So populating records for any/all
EDI/partner/in-house change requests etc. was simple, easy and straight
forward (dependancies were enforced in the appropriate dB data-dictionary
records (never in code, thus those too were browseable for changes to be
implemented at runtime). Initial loading/priming of the whole record
collection consisted of three phases, records of EDI structure, records of
EDI (spec.) "content" and then, more slowly and carefully, the "EDI service
buereau/provider" structures. That then made the use of the "FOOF! button"
for adding/editing a "partner pair/set" available. All source code was not
only available in micro-seconds (bug free first time, every time, when it was
got right the first time), but upon ANY change. A few auto-re-generated
browsers were "FOOF!ed" into existence and used to enter the FEW new/updated
record sets to "re-FOOF!" (totally) ALL the new source code in as little as a
few more minutes. From first inspection, it seemed obvious to me that some
core group of the early EDI spec. crafters had set things up the way they did
"just so" I would see that this (the above methods for utilizing interplay of
the elements of the EDI specs.), and apply those specs. "just so". And I
didn't have all that much help so I had to automate things at every possible
instance (my son turned out great tho, and is a very highly paid contractor
at code-banging, as he learned "this stuff", for a cash incentive).
I suppose change management at other sites of EDI use/implementation may have
had difficulties, which bid them look to XML for answers that IMHO, do reside
within EDI as I have experienced it. Thus, to me, XML would seem to be a
"huge-er" set of "datums to be dealt with" to solve problems that may already
seem difficult, and IMHO would be easier to resolve in EDI, at least at first
effort. Otherwise, just (e)mail (html) forms back and forth like we all
did/do with the postal system for paper forms, and write some big filters to
pull out the transaction data etc. to reorder to stuff into your own in house
version of the forms you get from "them". But we will let each other type on
each others forms from their own seat (email would be the first thing you
could eliminate from such a system; iff you are a world class computer system
security expert who can remain always current).
Regards,
Jim Cunningham
P.S.
If someone brings up the issue of record lock delays etc., remind them to
look back to the old paper systems for guidance.
e.g.
Order entry(/editing), you used an order entry form (workfile, not! a dB
record), and you could even tear off yours and give the pad to others. You
filled it out, checked your work and submitted it for approval. Only then was
the typewriter/typist "locked" from access by others. Then the order file
folder was "locked" while your typed order was placed therein in the
appropriate order (a real short time). CC: copies were then
distributed/cross-indexed and the original order-FORM should have been
archived by a chronological (my recommendation) index method (what happened
before/after what).
Enter you order into a workfile, NOT! ad dB record (w/record lock, and worse,
and index lock); validate whatever, whenever, however.
Here's the beauty part: at the appropriate moment, trigger the running of the
code that transposes (enters) the workfile/psuedo-record order data into a
new, then created, order file record. That sould take micro-seconds, during
which you should feel free to use the biggest lock you can find. It is held
for those fractions of a second and released/destroyed. What locking
conflict?
P.P.S.
When such forms exist (bc. the system DOES go down, yet the customers call
anyway) AND "look and feel" the same as the data entry screens (are laid out
the same), training newbies to fill out yet another form has no trepidation
for them, especially those who have never "used the computer" before. Then
when they do get at the screen/keyboard, finding it familiar, they feel
really "cool" (empowered).
When you change screen forms, change the paper (backup) ones FIRST, so you
can use them in training re: the new screen layouts/procedures. Then those
users will also "get with the program" of those changes with "much coolness".
And anyone pressed into service to quickly be able to do the same work can
be trained quickly and cool-ly.
It's the user, stooped.
No, it's the stooped user.
No, it's the stooped user, stooped.
I knew a guy, he was sooooo stooped, he walked bent over like this .....
Man! was he stooped. Traffic accident or something.
add homonym
Yeah, I know. I told that one here before.
But this time, I have a question.
How come that's funny?
The other day I was talking to a lawyer, when in passing, he mentioned he
gave blood that day.
A lawyer, gave, blood!
Now that's! funny.
Which three words don't belong in the same sentience?
He's a wonderful person, father, husband (his lovely wife testifies in
public), friend and lawyer (prosecutor) too. But he part times as a band
leader/comedian at bar association events, and he didn't even catch himself
when he uttered that sentence. I advised him he would likely get a lot of
mileage out of this one.
As far as something like that occuring in the written word goes: That, XML
could handle. Bc. of the potential richness of content about content in a
single container. Software systems, completely embodied in dB records,
indexes and data dictionaries (multiple, cascaded), that "blossom" into
generators that auto-FOOF! out the preprocessors, templates, tokenized
preprocessor input records, to then blossom and auto-FOOF! out all the source
code in an elite directory structure, all specifically optimized for the
detected OS, locale, environment and even the questionaire-detected
audience. ANYTHING that isn't "in the dB" isn't in the right place. Yeah,
the code belongs in there too; especially the code; FULLY normalized, of
course. That's the sort of thing I keep trying to get back to. Yeah, I
built the auto-FOOF! internationalized documentor-to-file/hardcopy/screen too
(first!, 8 or 9 years ago; that's where/when I got all these ideas, the
documentor just "cleaned up" the source; translated it via dynamically
contructed structures of structure to tranpose the source code to "outline
form" in English, extensible to other languages).
That these automatons could be easily populated with records to allow them to
reproduce, modify and improve themselves has not escaped me.
That XML could be used to arbitrate "what's funny" (in the written word) has
not escaped me.
------ 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
