OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Udell & Dickerson, good reading

[ 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.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS