Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Are the publishing users happy? Why not?
 At 12:57 AM 2/19/2003, Rick wrote: >I think anyone (except perhaps enormous Brainiacs) who has written a book or >any kind of professional material will use a checklist. I once asked Don >Stollee >(a project manager who works on large markup projects, often defence or >aeronautical) what the most important thing for efficient markup was: his >answer >was dividing the job up into subtasks: rekeying tables would be one tasks, >marking >up references would be another. People usually work the most efficiently when >they can concentrate on one thing at a time. > >That was my reference to Adam Smith. The industrial revolution was based on >specialization and the division of labour: either between people or with >people >serially taking on different roles. People and tools that encourage users >to try >to do everything simultanousely will only help efficiency if the task is >simple >(i.e. less than HTML-sized DTD), or the steps are really fixed (i.e. a >form). >Otherwise, they may positively get in the way. I agree with Rick, and I think it gets close to the heart of the matter. Much of the problem XML faces in publishing applications is, I think, an expression of the current mis-fit between the strengths of the technology, and the needs of the individual user. Like any technology, XML has costs and benefits, but it really begins to pay off when applied at the level of the organization (or larger, the internetwork) -- where, for example, it makes sense to engineer and manage workflow in the way Rick describes. Yet from the vantage of the individual within such a system, costs are significant but benefits may not be so evident. (To often they take the form of "well it makes it easier for us!") So the user has little or no incentive to embrace the technology, unless she or he happens (like many of us) to "click" with the big vision. Not common. And as an industry (or rather, as a culture), publishing has always been notoriously and necessarily sensitive to the foibles and resistances of the individual. As long as the scale of its "fit" is larger than the single user, XML will have a hard push to get mindshare, no matter where it appears in the plumbing. Office 11, Open Office, and so forth will make it easier to engineer and implement XML at the level of the organization; but this requires top-down energy. The technology won't really spread on its own until it offers tangible, immediate benefits to the user as a user. This is the way HTML and e-mail spread: because e-mail was so useful, offices and institutions couldn't keep it out. The web itself came into wide commercial use not because of top-down initiatives but because the top, after a certain point (maybe 1996?) had to face up to what the bottom had already started doing. For generic markup, XML improved this situation markedly over SGML, but the tide has since turned again. When the specs and technology are so complex, it pulls it out of reach of the little guy. Two steps forward -- well-formedness (separating parsing from validating) and XSLT? -- and one step back (name your favorite XML albatross). I still have hopes, but I think it's going to be a long haul. One thing I think would help would be a toolchest that would allow a third-party developer or integrator to deploy a really nice, lean editor customized for a particular document type. Rick's Topologi Editor targets an important niche; I'd also like to see something like XMetaL only (a) not locked into one OS, (b) lighter and cheaper, and (c) packageable for redistribution. (XMetaL is also a fine product but it isn't *quite* there -- in fact it is overtly designed for deployment by organizations, not to be picked up by end users at their own initiative to get some job done, or shared within a looser-knit community.) Even if (especially if?) it handles only one document type at a time, as long as it can do that nicely, it might succeed at getting the author's view off the markup and back onto the content -- yet within an environment where authors are safe from themselves. In fact, such a DocBook editor or TEI editor or XML Blog editor (you could build any of them with this toolkit) might succeed -- assuming it's provided with a tag set well-designed to achieve something they are focused on -- where generalized markup editors still intimidate authors who don't see what generic markup gives *them* (when all they think they want is italics). Dave Megginson wrote: > > Structured authoring is hard. > >It's hard to learn but easy to do once you've learned it. The trick >is figuring out when it's actually worth making that initial >learning investment. And that decision is one that most authors have to make on their own. Regards, Wendell ====================================================================== Wendell Piez mailto:wapiez@m... Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== 
|
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
|
|||||||||
