TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I am not persisting with this discussion along the given lines. However, I
would like to make a broader point here with the help of this example. It is
situations like these, when we need to make a choice between 'persist'
and not to 'persist' that make the job of a technical writer so much fun.
My own take on this would be to completely do away with the word persist and
rephrase the entire text to make it simpler. Of course, the target audience
decides the kind of terminology to be used.
On 6/5/07, Jan Cohen <najnehoc -at- yahoo -dot- com> wrote:
> I saw the IBM definition too. But given the usage in the original
> > "Once we have validated, or failed to validate our data, we
> > need to persist it. (Or at the very least we need to make the
> > decisions not to persist it.) We have an number of ways to
> > persist our data depending on the scope of the persistance.
> > For a single webform, we may be persisting the information
> > back into the form input fields. Or we may persist it to a
> > session if we want to data to remain for the entirety of the
> > user's visit. We may even persist it to a database for long
> > term storage.\ "
> I'd say the intent was to ensure a certain set of data could be
> "preserved" across two or more sessions, e.g.:
> 1. open a session,
> 2. populate the session with some "persistent" data from a database,
> 3. fill in some additional data, make changes to existing
> data, or just reuse existing "persistent data" as part
> of a new record,
> 4. store the entered/changed data in the database,
> 5. close the session,
> 6. open a new session,
> 7. retrieve the "persistent data" from the database,
> 8. and so on and so forth.
> In fact, if my interpretation is correct, a collection of "persistent
> data" could be made up of subsets of "persistent data" that could be used in
> different ways and varying combinations. I can see data that's constantly
> reused across multiple sessions (more than two) as persistent data that
> usually does not change (e.g., data common to multiple records); as well
> as data being entered during a specific session (e.g., a name and address)
> being stored as a new record for reuse, in-turn becoming persistent
> data. After all, isn't that how a database is used? Or am I off the mark?
> Though I can kinda imagine the "persistent" (npi) folks I used to work
> with nodding their heads in agreement, I'd still prefer the use of
> "preserve," unless I was writing specifically to an audience made up of
> "persistent" people.
> They can be kinda funny about stuff like this.
> jan cohen
> "iFaqeer (SIA)" <techdarwaish -at- gmail -dot- com> wrote: Just read the IBM page. It
> doesn't seem to imply the "to persist data" usage:
> To be maintained across session boundaries, usually in nonvolatile
> storage such as a database system or a directory.
> (1) A characteristic of data that is maintained across session
> boundaries, or of an object that continues to exist after the
> execution of the program or process that created it, usually in
> nonvolatile storage such as a database system.
> (2) In J2EE, the protocol for transferring the state of an entity
> bean between its instance variables and an underlying database. (Sun)
> Pertaining to data that is maintained across session boundaries,
> usually in nonvolatile storage such as a database system or a
> I say we write around it as long as we can--and hope it is a passing fad
> You know, something like "store it as persistent data" or "store it in
> persistent form/configuration" etc.
> When it passes into the language (like "automation", "online", and so
> on) or, importantly, the specific accepted usage of the domain one is
> operating in, we can get with the program.
> Create HTML or Microsoft Word content and convert to Help file formats or
> printed documentation. Features include support for Windows Vista & 2007
> Microsoft Office, team authoring, plus more.
> True single source, conditional content, PDF export, modular help.
> Help & Manual is the most powerful authoring tool for technical
> documentation. Boost your productivity! http://www.helpandmanual.com
> You are currently subscribed to TECHWR-L as raj -dot- machhan -at- gmail -dot- com -dot-
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/ for more resources and info.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-