Eric Armstrong wrote:
> Murray Altheim wrote:
> > ...One of our engineers did a fairly comprehensive study
> > of document "components" with an eye on reducing translation costs.
> > Sun localizes its document pool across quite a number of languages,
> > which is very expensive, so the idea was to try to save some money
> > hiring translators.
> > What he found was that the cutting and pasting of such components
> > was frought with difficulty, as they were originally written by a
> > [supposedly] intelligent author for a particular purpose in a
> > particular context. That these components (let's really call them
> > "document fragments") are somehow modular and reusable seems rather
> > suspect to me...
> This may come as a bit of a surprise, but I totally agree with
> you. When a document is written, transitions play such a key role
> that the idea of "modular reuse" is effectively moot.
> Another way of saying that is: Given the tools we have at our
> disposal, the work products we have created are ill-suited for
> modular reuse.
> However, not all classes of documents fall into that category.
> Here are three that do not:
> * A granular email system.
> * An automated (ideally human-mediated FAQ system)
> * A DKR
> Now, these are systems that *could* benefit from modularly
> reusable material. When systems exist which expedite the
> authoring and access of such material, we may well see a shift
> towards more modular writing. (Much material will still depend
> on sequencing and transitions, however, so not everything will
> fit into that category.)
I might add to your list XTM topic maps. <topic> elements need to
commonly be reused as topic maps are merged, but upon merging the
IDs used as identifiers, perhaps "published subject identifiers"
may be lost.
It's not that I don't understand or agree to the need for modular
reuse (heck, I wrote the modular XHTML DTDs so I'm big on m12n),
but that as you say, I don't either know how quite to proceed
given our current pool of tools and the direction XML is going
with namespaces et al, which may *seem* to promote such things
but seems to me to simply be getting inordinately complex.
Murray Altheim, SGML/XML Grease Monkey <mailto:email@example.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025
america was once a paradise
of timberland and stream
but it is dying because of the greed
and money lust of a thousand little kings -- archy (1927)
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:05 PDT