[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Udell & Dickerson, good reading
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@w...] 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|