[
Lists Home |
Date Index |
Thread Index
]
I take away the same lessons I learned
doing the SGML ATOS conversions: simple tools are more
reliable even if the process is uglier. It is harder
than some think to hide the brackets and still have a
good feel for what one is doing to the documents. Little
problems turn into big ones the deeper one macroizes
the pipeline. That is why I could never understand
those who wanted to toss away DTDs without a simpler
replacement like RELAX NG.
But one hopes these tools get replaced eventually
by tools specialized well for given tasks.
Udell seems excited by XDocs/InfoPath. That's interesting.
When documents can become reliable data sources for
integration into fused views, some problems of business
process design get a lot easier to handle. GIGO of
course, but human competence is still the final
frontier of better computing and that is why the
editors are there, but that isn't the whole problem.
Drift happens naturally as views change over time
among entities with different responsibilities,
strategies, and backgrounds.
How can XDocs help? One optimistic vision based
on real world experience: systems that do away with the
need to heavily front load the downstream analysis
tools really do improve the process because they
enable fused views, eg, quick visibility into
decisions made over months by multiple lightly
coupled human entities as they affect the next
stage of a process. For example, from the
commitments made by the development staff in
response to the RFP proposal team, then to the
contracts folks who commit your company to work,
then to the project manager who on award must
finally pull all of that together and come to
terms on a schedule with a customer who by now
may be a completely different set of decision
makers than those that originated the RFP. We've
done this with CRM systems, with relational dbs,
and so on. It would be better if we can do it
with the records of authority (the documents)
and not have to re-enter those and risk multiple
copies, transcriptions errors, human oopsies, and
so forth.
As to authors: long ago and far away, they resisted
the initial attempts to control production with DTDs
that initialized the editing system. Then they began
to see they could go faster with less time spent pouring
over the 38784 standard both entering and at publishing
time. Integration into the final discs was much faster
and completely automated, so weeks of effort turned into
a weekend of the droids working instead of the humans.
All of that took about a year and half to get right,
but by then, we couldn't have pried the machines away
from the authors with sticks. Proof is always in the
pudding where new tools are concerned. It's a Show Me
world in the production suites.
len
From: Bill Humphries [mailto:bill@whump.com]
On Tuesday, February 11, 2003, at 10:55 AM, Dare Obasanjo wrote:
> XML is not a panacea. Film at 11.
http://www.yarinareth.net/caveatlector/archive/week_2002_12_15.html#e001172
Cue the video loop of Steve B with a new phrase dubbed in: "Editors,
editors, editors, editors, editors!"
You have to have an editor in the process, otherwise your writers find
clever ways around your schema and drift sets in. It isn't much work if
it's done regularly.
|
