[
Lists Home |
Date Index |
Thread Index
]
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@mulberrytech.com
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
======================================================================
|
