[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: The general XML processing problem

• To: xml-dev@l...
• Subject: RE: The general XML processing problem
• From: Doug Rudder <drudder@d...>
• Date: Mon, 15 Jul 2002 14:36:09 -0500

Sean McGrath wrote:
> Not only that but any attempt at superimposing a singular process view on 
> the data will
> just bend the all data out of shape and further distort an already
unavoidably
> distorted model of reality:

Amen.  This is an issue the company I work for ran into shortly after
switching from our old typesetting system to a markup-based system
(initially SGML) nine years ago.  At the time, we were basically a print
publisher that wanted to branch out into electronic products.  However,
while trying to convert our content into SGML and simultaneously maintain
our print products, including monthly looseleaf updates, quite a few
print-specific processing instructions and "creative tagging" were
introduced into the data to facilitate print.  The original DTD became
centered around "print groups".  The first time we tried to repurpose this
content for an electronic product was nearly a disaster.  Believe it or not,
it took a while to convince the tech writers/editors that just because the
page looked okay did not mean that the markup was all right (e.g.,
<para><emph type="italics"> is not a valid replacement for
<section><title>).

A few of years later, one of our electronic products developers wanted us to
embed HTML directly into our XML content to facilitate a given application
-- this despite the fact that not all electronic products and no print
products utilized HTML output.  Same issue as before, different application
format.

Developing a standardized, media-neutral content model was a daunting task,
and getting user buy-in was even tougher.  But we did it and it was
definitely worth the effort.  It even led to a decent article (at least I
think so, but then I wrote it :) ) on Technical Writing and XML: Reconciling
Editorial License with Structured Markup.  It goes a bit farther afield than
this discussion, but for anyone who might be interested it can be found at:

www.idealliance.org/xmlfiles/issue37/default.htm

If the purpose of the XML content is to be a portable, reusable, and
flexible set of information, embedded processing and formatting instructions
can be counterproductive and should be avoided if possible.

• Prev by Date: Re: generating DOM from ill-formed HTML docs
• Next by Date: Re: The general XML processing problem
• Previous by thread: Re: The general XML processing problem
• Next by thread: RE: The general XML processing problem
• Index(es):
  • Date
  • Thread