In a message dated 2/1/01 10:47:31 AM Eastern Standard Time,
[EMAIL PROTECTED] writes:
>
> There is one thing which these threads seem to miss which I believe is
> indisputable - the concept of variability. That is business processes,
> business models and their corresponding revenue streams change frequently
> and even on a daily basis - for a variety of reasons - regulatory, market
> driven, product or service functionality. There is a need now for mass
> personalisation (even in B2B) all the way down the supply chain.
>
Of course, and well said.
But, I have addressed/trumpeted that for years now. Yet, I proposed a
soultion all along. As long as the code is static, you nailed it. So,
static code must come to an end, not necessarily EDI etc. A closed loop
feedback control system of response to document/communication input, which
could certainly accomodate most existing and even new work on heuristics,
fuzzy logic especially, seems a reasonable approach to providing/craftng a
solution to the "problem" one "last time".
A finite state automaton that "draws all" from dB records that are simply
created and updated by crummy little browser code, at the most if not
automatically, which triggers a code generator overlaying record content on
templates of "typical" "actions", appropriately getting fired off for
(repeatable and automatic) instances of utilization of said communication
data receipt and response, is (finitely) quite doable. ANY assembly
constructed of finite components must itself be finite (surender to
cataloging), which is what we are dealing with here, catalogue updating,
change. Getting to the closed loop feedback control system is the only real
work left to do. IMHO. Scanning in the tables of the standards bodies to
auto-generate a Q&A session to index those table's hierarchy/relations,
followed by the code generation to produce cascaded
browsers/reporters/"outputters" to draft such communications; and the
generation of inverse cascades of comunication data receipt entry to produce
any desired response has, in my own experience, been a more comfortable
approach for me, due in no small part to the clarity available from the then
existant table/relation information. Which "information" (about the(about))
is reinforced and rerevealed by reprinting of the usual dB reports. It's the
"about (the about)" (sic) layers/levels-of-indirection gambit, I suppose.
Working with the clarity of that report output quickly and ever strongly
imparts ongoing reinforcement and thus clarity of "just" "exactly" "what we
have here" and thus, how to go about/continue ending up with what needs to be
ended up with, here/there/everywhere/wherever.
But hey, thats just the way I perfer to play with this stuff. It takes a ton
off the job of trying/having to remember all, and all the interrelationships.
Bc. Then, changes like new or even unknown segments, tags, even standards
body tables has thus become "programmable" as far as my response is
concerned. And did I say FAST? Then, it's also quite "teachable" and
offloadable. Beats eons of re-re-re-re/re-re-re-re-reading (AHHHHHH-RETHA!)
my own code to redivine "what the hell was I thinking then?", way.
Regards,
Jim Cunningham
P.S.
Most, and most are Apache (a patchy), web servers began doing/effecting that,
not too recently, with open source, for automated dynamic
freshness/timeliness of user/visitor perception management. Marketing people
use tools to make the new pages for the catalogue of same and FOOF. But, a
LOT of that work is in PHP lang., which might be worth the short time it
would take to learn to at least read PHP and find out how well suited it is
to that task. (IFF you are up to speed on ObjectOriented mindset)
------ 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 receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
