In a message dated 2/1/01 12:08:41 AM Eastern Standard Time,
[EMAIL PROTECTED] writes:
>
> Registry driven transformation will indeed be largely automated.
>
> True the business analyst will have to create the Registry entries,
> but once that is done, the SME will be re-use enabled, and also
> able to plug in process based solutions by selecting criteria
> and application interfaces at a higher level.
>
>
David,
(Really) sensible defaults seem likely to obviate even that work, don't you
think. An automaton, upon seeing new tags, fields, data, even document types
and transaction sets, would't be ready for beta w/o also testing those
defaults. Press of business aside.
Regards,
Jim Cunningham
P.S.
A document receiver should be table driven (dB records, actually) and create
new dB records to receive the document content data, notice new tags,
fields, types etc. and do some table driven list of activities then, like
email or page somebody. I did this in EDI, loooong ago.
I always printed such a "document", and in a pleasantly short time, the
client office staff could alway figure out it's "gist" and do the deal. EDI
in XML increases the likelyhood of this, perhaps too much (tag:seg-id::data
of label:label;word). Yet a default format for anything bearing "unknowns"
should simply tab data within table data that is a "wrapper" citing
tag/seg/etc. "descriptions", to elucidate to laymen, the answer to the "say
what?". Further, an additional parallel set of records, in lay terms,
producing a layperson's default version of such a document that tries a
little harder to be useful to them is a better solution approach.
I learned almost immediately, when I started working on EDI, If we got a PO,
nothing was going to stop us from shipping and invoicing the material, takin
care of biz ness. Too much work and money went into aquiring such
opportunity for any CEO to let a "typo" cause some dweeb to reject that
PO/piece of business. And, we had a default (manual entry screens) method of
replying to a typo'ed doc. that wouldn't auto-reply; a "complete business
system".
P.P.S.
Seems we will ever get new-to-XML(EDI) who want to bang code and worry about
the documentation and analysis when they get "something" working (that they
then have a stake in, perhaps have "bragged on", before they even knew what
it had really turned out to be). Hope not, this is a "profession". The
office staffs response to flawed documents not interfering with biz may be
the best point of view, upon which to formulate activity (BOTTOM up). In a
case such as this, perhaps, at least. Remember the paper system. A PO came
in for a line-item the clerks couldn't ID. The sales rep for that account
got notified at the very next call in, and he and his marketing management
saw another wonderful opportunity to make contact with a buying influence;
showing them how much we cared about his needs that we were being given the
opportunity to manage. To marketing professionals, these typos were manna
from heaven (the typo was theirs; you don't wnat to make cointact (sic) as
much about your typos; do you),
A short aside:
I always started with a client by letting them go first and "spew the dream
they wanted to live" (a a major stakeholder influence opportunity for them,
instead of the "dream they were currently living"); so that I could always
follow that with the same old question;
"Sooooooo, what do you want to end up with right now?".
Then, and at any and every contact, I would ask the same question again,
"roll" the answer around with them until "we" could express it as a single
sentence (compound senteces were allowed for their "how to" ideas
(expectations); make a show of writing that sentence down with date and
initial; rereading it to them to then ask them to initial; and then: just go
do that. If you can't express an idea in a single sentence, the matter seems
worthy of further investigation.
Bottom up; it seems the only way to assure you are doing what they need done;
the job. That this "alllows" for advising, recommending, etc., which
requires you start over with the question>signed-sentence sequence though,
should never be overlooked. But it is a "way" to document (bill) the
professional content that too many think ought to be free. You impart on
them an acknowledgement of your professional contribution, w/o letting them
get fuzzy on the "contribution" part. Yet much if not most of such
professional contribution may be better managed post
concept/model/demo/prototype, where you need above all at that point, to
demonstrate you did exactly as asked/initialed-by-them, first off. It's
always so much better to have them report up that "success" has begun and
from their internal point of view, via their guy, looks good (is worth the
money they owe you so far); internal inter-dept. budget billing etc. aside
(if you work for same firm).
For me, this approach "ended up with" the EDI system I referred to above,
rather quickly, with the resultant fault tolerant "clerk" empowerment
mentioned. They didn't call me in a panic/resentment based mode about "my
code" imperiling their biz. or customer relationship, which they properly
valued immensely, and could tolerate NO risk for.
------ 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
