[
Lists Home |
Date Index |
Thread Index
]
And so I will also forward the response slightly ammended:
It is the multiple audience problem where each
audience has a preferred interpretation and
there is cognitive dissonance (lack of consistency)
produced by the attempt to serve both with
the same message. We sometimes say that the
data model plus a transformation solves this
problem but it is not true in all instances.
The best one can do is test and compromise,
then try to prevent a particular case in a
particular situation with a high sensitivity
to the perceived inconsistency that could create a
catastrophic result. The programmer vs author
issue is not a problem to be solved; in the
words of a trendy management theory, it is a
polarity to be managed.
People are paranoid because life IS dangerous
and has only one outcome. You can pick the
route but not the destination. :-)
len
-----Original Message-----
From: Doug Rudder [mailto:drudder@drugfacts.com]
Len Bullard wrote:
> XML has almost single handedly given markup
> the reputation of being "computer friendly
> and author unfriendly". Why? SGML was actually
> friendlier to authors and hard on the programmers.
> We know why. It isn't always a good thing
> to insist on the programmer as the primary
> beneficiary.
Nice observation! While it is true that we don't want "editorial License"
to run wild, we also do not want to let optimizing for programmers to damage
the integrity of the content. The company I work for publishes drug
information references in multiple formats;
as such, consistency of organization and presentation is important, both
from a human readability standpoint and from the standpoint of repurposing
the content for multiple outputs. XML/SGML can be a valuable aid in
maintaining consistency for both purposes.
But there have been instances where DTD change requests have been submitted
to accommodate inconsistent authoring (often subtle, and the requestor does
not realize it is the same content presented in a different way); there have
also been instances where we have been told: "We should do everything we
can to make it easier for the programmer", including damaging the integrity
of the content model (this argument has almost always involved making it
easier for a specific instance, not for *all* instances, even though the
requested change affects the markup for *all* users). Quality of content
should *not* be sacrificed to benefit programming if at all possible.
Striking the balance between the need for flexibility in authoring and the
need for adequate ease of programming is problematic at best. To weight the
technology too much either way can have a negative effect on its overall
usefulness.
=======================
Douglas Rudder
Publishing System Specialist
Facts and Comparisons
Phone: 314-216-2227
e-mail: drudder@drugfacts.com
www.drugfacts.com
=======================
|
