Re: Baiting for the single source rant

[SIANNON -at- VISUS -dot- JNJ -dot- com]

Andrew Plato responds:
>> The bottom line is that what this rant is about, 
>> is that we are all trying to reduce the authoring 
>> of redundant text we have to author and maintain
>> over a document's life cycle 
>
> No we're not. I am not trying to reduce redundant text 
> authoring. Many of my clients could care less about 
> this issue. We are way more concerned with the technical 
> accuracy of the text. God (aka B. Gates) invented
> copy/paste to handle redundant text. We surely don't 
> need to spend 2 years and $900,000 to solve a problem 
> I can solve with [CTRL][c] / [CTRL][V].

The problem with redundant text for many of us isn't the actual 
implementation of the updates, but remembering where the updates are 
scattered within the docs:  this one point needs to be updated in 5 places, 
while this other one needs to be updated in 3 places, and this other one in 
6 places, often among different docs. While I can honestly say I have a 
more comprehensive understanding of the system as a whole than any of the 
individuals on the development team, I cannot instantly recall in how many 
places details about the structure, sequencing and derivation of unique 
carton IDs may appear (especially when they can be generated by at least 
five different functions, spanning two different applications, using three 
different algorithms).

I think a lot of people are employing single sourcing not for the 
implementation of changes, but rather for the help in mapping where 
replicated conceptual elements appear in the docs.  Often these replicated 
concepts manifest with different levels of detail, different tones and 
perspectives, depending on the doc in which they are used.  In this 
instance, only Bill's third example of single-source usage would be usable, 
and it could have serious potential issues. Whether those issues outweigh 
the assistance the methodology could provide in maintaining the content 
integrity is the fuzzy part.

That's why my question for the rant is not "should single sourcing be 
used?" but rather "how would single sourcing address these specific 
issues,--and could it be effective?"  As of yet, this question is 
unanswered, because the focus has been on the mainstream usage of the 
technology (understandably), which predominantly focuses on the management 
of output, not content.  I'm trying to identify whether single-sourcing, as 
a tool/method, is capable of addressing a specific content-management need: 
providing a cross-document conceptual index for use in identifying 
downstream revisions needed after an incremental change in a specific 
element within a complex system. (lather, rinse, repeat)

Most systems I've seen cannot be used for this effectively, because they 
are too focused on repurposing into specific formats, and therefore 
constrict the way you can organize document elements.  It's one reason I'm 
trying to gain a better understanding of AuthorIT, since that is the first 
prepackaged system I've seen that allows such an extensive level of 
granularity -- I'm still having a dickens of a time dealing with the user 
interface on the demo version, so the jury is out on it right now.

I've been intrigued by some of the homebrewed systems mentioned here that 
work with markup languages, user-defined tags, and database repositories, 
but I haven't been able to determine whether they come closer to what I'm 
thinking of.  It may be an imaginary beast, in the end, but right now it is 
still but a question.

Anyone here have opinions on this? (yes, I know I'm asking for it)


Shauna Iannone
Tech Writer, American Computing Technologies,
currently supporting 3GT CIM at Vistakon
--------------------------------------------
I think, therefore I thwim.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A landmark hotel, one of America's most beautiful cities, and 
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

  +++  Miramo -- Database/XML publishing automation.  See us at  +++
  +++  Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion  +++
  +++ More info: http://www.axialinfo.com  http://www.miramo.com +++

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.