RE: Of myth and reality

[SteveFJong -at- aol -dot- com]

Sean, we seem to have different images of "single-sourcing," which allows you 
to argue in consecutive paragraphs of your reply that (a) a "single-source" 
document that contains separate blocks of text for printing and online 
display isn't single-sourced, (b) unless you want it to be:

(a) >> I never made a claim that that was single sourcing.
     >> Why do you say that I did? Why did you even bring that up?

(b) >> Why must single-sourced documents all have the same content and/or
     >> all have the same graphics and/or all have the same layout and/or
     >> all have the same fonts and/or all have the same use of color, etc.?

I believe you're saying that if I write the same thing differently in two 
blocks, I'm not single-sourcing, but if you write two different things, you 
are. Hmm ... 

The Macintosh "fat binary" analogy is quite apt, I think. The "fat binary" 
contained separate code for the 68K chip instruction set and the PPC 
instruction set, though the application could share resources (graphics, sou
nd, data, etc.). It was a single application from the user's perspective, 
though it was bigger, always contained dead code, and wasn't guaranteed to 
work the same on both platforms because the code was maintained separately. 
Despite Apple's assurances it was very easy to implement, I gather it was a 
pain in the neck, and it's not missed. To me, that's not single-sourcing, 
that's creative packaging.

A more direct historical precedent might be the S.S. Digital's attempt to 
create a reusable database of information modules, which foundered on the 
rocks of granularity and context:

* Granularity: How small must a module be? A map? A topic? A procedure? A 
paragraph? An illustration? A sentence? Unfortunately, yes... at which point 
the working writers' eyes glazed over, and who could blame them?

* Context: When you convey a piece of information, how do you know the user's 
context *a priori*? If you're talking about database backup, are you dealing 
with an experienced administrator (for whom it might be sufficient to write: 
"Use the dBackup command; ensure that you have 150% of the database size free 
on the backup media"), a beginner (for whom you would have to write in 
considerably more detail), or a student (for whom you would have to create 
and step through an example)? No matter how much we were told we didn't have 
to write differently for different contexts, we found that we did.

I know about SGML, but our implementation, VAX DOCUMENT, wasn't up to the 
task. Ten years later, XML has emerged as a practical means of reconsidering 
the problem (<yadda></yadda>), but few writing organizations are large enough 
to make it a cost-effective approach. And even at that, I expect the problems 
of granularity and context remain.

I think it would help to have a single definition of "single-sourcing" that 
includes the concept of create-once, use-everywhere. If you have to write a 
block of text twice or more, or modify a graphic twice or more, for different 
presentations, then you're short of the goal. I don't demand 100% confo
rmance; I'm realistic about the expectations of our audiences and the 
limitations of our tools. But clearly we want to get as close as practicable.

If we agree on that, then the question becomes one of overlap. If I have to 
jump through hoops so that I can have one file, or set of files, that 
contains printed and online (and Web and PDA or ...) information without 
significant overlap, I'm going to ask what benefit this has for the user and 
how much time and effort I'm saving as the creator/maintainer of the file(s). 
So... How much overlap are we talking about here? How much overlap have you 
achieved?

          -- Steve

Steven Jong--"Typo? What tpyo?"
mailto:SteveFJong -at- AOL -dot- com -dot- nospam
Home sweet home page: http://hometown.aol.com/SteveFJong

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Your monthly sponsorship message here reaches more than
  5000 technical writers, providing 2,500,000+ monthly impressions.
  Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

Buy RoboHelp Deluxe starting at only $798: you'll get RoboDemo, the hot new
software demonstration tool that's taking the Help authoring world by storm,
together with RoboHelp Office. Learn more at http://www.ehelp.com/techwr-l
---
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.