<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Writing&gt;Grammar</title>	<link>http://tc.eserver.org/dir/Articles/Writing/Grammar</link>
	<description>A listing of the most recently indexed works about Articles and Writing and Grammar in the field of technical communication (and technical writing).</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Writing&gt;Grammar</title>
		<link>http://tc.eserver.org/dir/Articles/Writing/Grammar</link>
	</image>
	<item>
		<title>“Verbing” Nouns</title>
		<link>http://tc.eserver.org/35743.html</link>
		<guid>http://tc.eserver.org/35743.html</guid>
		<description>I was disappointed yesterday when, while cruising Facebook, I noticed a national pharmacy company’s request for me to “fan” them. I simply cannot agree to become a fan of a company that thinks turning nouns into verbs is hip and thereby will increase its customer base. If they had instead asked me to “become a fan”, I may have indeed considered it.</description>
	</item>
	<item>
		<title>Subordinate Clauses and Commas</title>
		<link>http://tc.eserver.org/35751.html</link>
		<guid>http://tc.eserver.org/35751.html</guid>
		<description>Writers like to sprinkle their work with subordinate clauses because they add variety to sentence structure. A reading diet too heavy with simple sentences or even compound sentences becomes wearisome quickly. Subordinate clauses—also known as dependent clauses—used skillfully can add complexity and artfulness to writing.</description>
	</item>
	<item>
		<title>The Grammar Gravy Train</title>
		<link>http://tc.eserver.org/35585.html</link>
		<guid>http://tc.eserver.org/35585.html</guid>
		<description>When you set yourself up as a grammar expert it&apos;s better than being an expert on plastics. To be an expert on plastics you actually have to know something about plastics. With grammar the analogous thing doesn&apos;t hold. Nobody asks, nobody checks, nobody knows enough to get suspicious. You are free as a bird to publish any garbage you might want to type out.</description>
	</item>
	<item>
		<title>Order in the Sentence: Introductions</title>
		<link>http://tc.eserver.org/35587.html</link>
		<guid>http://tc.eserver.org/35587.html</guid>
		<description>The basic sentence in English is noun-verb-object: The player hit the ball. But we seldom leave it at that. We add things on the front. We add things on the back. We interrupt the sentence to say something else, and then come back to the sentence. We vary the basic sentence structure. And, in the most extreme cases, we substitute other things for the noun, the verb, and the object. All of this gives us great flexibility in creating sentences, but this very flexibility leads us to the problem of which variation to choose, and why.</description>
	</item>
	<item>
		<title>How To Use An Apostrophe</title>
		<link>http://tc.eserver.org/35496.html</link>
		<guid>http://tc.eserver.org/35496.html</guid>
		<description>A clear, well-illustrated guide to when one should (or should not) use an apostrophe.</description>
	</item>
	<item>
		<title>The Voice Speaks</title>
		<link>http://tc.eserver.org/35221.html</link>
		<guid>http://tc.eserver.org/35221.html</guid>
		<description>I learnt that a verb is the most essential part of speech.  So, I thought investing a little time to learn to use it better (if not master it) might not be a bad idea.  But then, there are so many aspects of a verb.  Can I ever say I learnt it? I can try one proven (presumably by the British) method: divide and conquer.  I will start with the voice of a verb, the much-talked-about aspect of a verb.</description>
	</item>
	<item>
		<title>Don&apos;t Lose Your Articles</title>
		<link>http://tc.eserver.org/35222.html</link>
		<guid>http://tc.eserver.org/35222.html</guid>
		<description>One of the difficult concepts to understand in the English language is perhaps the manner in which articles are used in a sentence. Over the course of one&apos;s life history, every student of English has had to face this nightmare at one point of time or another. The verbs are all in place and you know the nouns, the pronouns are fairly obvious, and the prepositions can eventually be worked out, but what comes before the word year and what comes before SMS is tricky.</description>
	</item>
	<item>
		<title>The Technical Stylist Meets the Definite Article</title>
		<link>http://tc.eserver.org/35028.html</link>
		<guid>http://tc.eserver.org/35028.html</guid>
		<description>Take the definite article. Please. The editors at SAS continue to struggle with the question of which SAS product names require the definite article and which require the zero article (linguist-speak for no article at all).</description>
	</item>
	<item>
		<title>Misplaced Modifier – Even WSJ Falls For It</title>
		<link>http://tc.eserver.org/34884.html</link>
		<guid>http://tc.eserver.org/34884.html</guid>
		<description>“Misplaced modifier” is a frequently committed logical error that even the most prominent publications fall for occasionally. Solution? Move the modifier clause right next to the subject of the sentence.</description>
	</item>
	<item>
		<title>Which Way Your Sentences Branch – Right or Left?</title>
		<link>http://tc.eserver.org/34785.html</link>
		<guid>http://tc.eserver.org/34785.html</guid>
		<description>Try right-branching sentences in your technical documents for higher comprehension. Right-branching sentences start with the subject, follow it with primary verb (or sometimes the other way around if the verb is in imperative/order mode), and then end with modifiers and other relevant information. What branches off to the right of the subject and the verb is all the additional information you want to get across.</description>
	</item>
	<item>
		<title>Technical Writing - Writing in “Standard Written English”</title>
		<link>http://tc.eserver.org/34432.html</link>
		<guid>http://tc.eserver.org/34432.html</guid>
		<description>As technical writers, we’re much better off when we write in a way that follows the dictates of Standard Written English (SWE). We can believe all we want that one person’s way of writing is just as good as another. And, in private use, it is. But we know perfectly well that a person who writes the kind of material we do who doesn’t have what’s generally considered “good” language skills won’t be considered a professional - and won’t get work.</description>
	</item>
	<item>
		<title>Obsessed with Possessives</title>
		<link>http://tc.eserver.org/33886.html</link>
		<guid>http://tc.eserver.org/33886.html</guid>
		<description>We see it everywhere: our schools, our places of business, even in notes stuck on our refrigerator. Yes, my friends, I’m talking about apostrophe abuse. The Obama administration, faced with two wars and an economy teetering on the edge of disaster, is unlikely to make this a priority. So it’s our duty as professional communicators to stamp it out.</description>
	</item>
	<item>
		<title>One Space Or Two Spaces?</title>
		<link>http://tc.eserver.org/33450.html</link>
		<guid>http://tc.eserver.org/33450.html</guid>
		<description>When I began writing technical documentation and courseware for Guru Labs, I asked a question during training about whether we should be putting two spaces after a period, colon, question mark and exclamation point, or one. The answer shocked me, as I was hoping for the standard answer as a means of teaching the rest of my colleagues. The answer was ONE space, not two. Then, I listened to the argument.</description>
	</item>
	<item>
		<title>Basics for Communicating Clearly</title>
		<link>http://tc.eserver.org/32126.html</link>
		<guid>http://tc.eserver.org/32126.html</guid>
		<description>Like the pronouns I, he, she, we, and they, the pronoun who is used as the subject of a verb.</description>
	</item>
	<item>
		<title>Tackling Typical Grammar Problems</title>
		<link>http://tc.eserver.org/31760.html</link>
		<guid>http://tc.eserver.org/31760.html</guid>
		<description>This training podcast provides examples as well as explanations and tips for dealing with a few grammar or usage problems that occur for many engineering and technical professionals who have to communicate in a hurry, via, for example, email. Listen for ways to know when to use can or may, affect or effect, it&apos;s or its, and also me, myself, or I.</description>
	</item>
	<item>
		<title>Semi-Definite Rules for the Indefinite Article</title>
		<link>http://tc.eserver.org/31183.html</link>
		<guid>http://tc.eserver.org/31183.html</guid>
		<description>Technical writing–perhaps more than any other sort of writing–gets read and used by people from every corner of the Anglophonic world. And people don’t get less sensitive to perceived slights or the appearance of cultural insensitivity because it’s a manual or help page. If anything, they’re more sensitive in such a circumstance.</description>
	</item>
	<item>
		<title>Every Noun Can Be...</title>
		<link>http://tc.eserver.org/30358.html</link>
		<guid>http://tc.eserver.org/30358.html</guid>
		<description>When is a noun not a noun? When it&apos;s been verbed. A lot of verbing is going on, as you&apos;ve probably noticed. In fact, it&apos;s happening so frequently that I think we&apos;d better come up with a name for the part of speech produced by verbing a noun.</description>
	</item>
	<item>
		<title>Nancy&apos;s Wordsmithy: Rules You Don&apos;t Have to Obey, Part III</title>
		<link>http://tc.eserver.org/30356.html</link>
		<guid>http://tc.eserver.org/30356.html</guid>
		<description>The funny thing is, this rule should be running out of steam, because certain standards of written English have changed in ways that make the rule at least partly obsolete. Learning it is kind of like learning to change a cloth ribbon on an old manual typewriter.</description>
	</item>
	<item>
		<title>More than &quot;Correct&quot;</title>
		<link>http://tc.eserver.org/30338.html</link>
		<guid>http://tc.eserver.org/30338.html</guid>
		<description>I think it can be dangerous for a technical writer to be a grammar expert.</description>
	</item>
	<item>
		<title>Passive Voice Is Redeemed For Web Headings</title>
		<link>http://tc.eserver.org/30197.html</link>
		<guid>http://tc.eserver.org/30197.html</guid>
		<description>Active voice is best for most Web content, but using passive voice can let you front-load important keywords in headings, blurbs, and lead sentences. This enhances scannability and thus SEO effectiveness.</description>
	</item>
	<item>
		<title>Assembly Instructions for a Correct Sentence: The Sentence Diagram </title>
		<link>http://tc.eserver.org/30080.html</link>
		<guid>http://tc.eserver.org/30080.html</guid>
		<description>This workshop explores the whys and hows of sentence diagramming. Knowledge of the time-honored technique can aid editors, writers, and instructors in preventing and correcting pesky errors in sentence structure, including dangling modifiers, misplaced modifiers, and faulty parallelism. Diagramming offers the familiar look of technical drawings, the comforting feel of pencil on paper, and unmatched analytical potential.</description>
	</item>
	<item>
		<title>Emphasize This!</title>
		<link>http://tc.eserver.org/30051.html</link>
		<guid>http://tc.eserver.org/30051.html</guid>
		<description>Technical communicators tend to be problem solvers. We ask ourselves, &apos;How can I make this better?&apos; We don&apos;t want our instruction material to simply be serviceable; we want it to help make our readers&apos; lives easier. One way we do that is by anticipating mistakes that users might make if they don&apos;t read carefully. We use various techniques to emphasize material that could otherwise be overlooked. Some effective means of drawing the reader&apos;s eye to important material are presented below. Note that this article doesn&apos;t address safety messages. For proper use of safety messages, consult your corporate guidelines and the American National Standards Institute (ANSI).</description>
	</item>
	<item>
		<title>Some Thoughts on Teaching Grammar to Improve Writing</title>
		<link>http://tc.eserver.org/29886.html</link>
		<guid>http://tc.eserver.org/29886.html</guid>
		<description>The conviction that writing can be improved with a knowledge of grammar has prevailed for quite a long time. But research has shown no correlation between grammatical knowledge and writing ability.</description>
	</item>
	<item>
		<title>It&apos;s All Relative</title>
		<link>http://tc.eserver.org/29794.html</link>
		<guid>http://tc.eserver.org/29794.html</guid>
		<description>When it comes to relative pronouns, incomplete knowledge may lead to frustration and confusion. The pronouns that, which, who, and what serve as relative pronouns when they introduce a relative (or subordinate) clause.</description>
	</item>
	<item>
		<title>Equal Time: Grammar and Composition: Myths and Realities</title>
		<link>http://tc.eserver.org/29377.html</link>
		<guid>http://tc.eserver.org/29377.html</guid>
		<description>Let&apos;s resist seduction by the mythologies of teaching and keep our grasp on the realities of learning.</description>
	</item>
	<item>
		<title>America the Beautiful</title>
		<link>http://tc.eserver.org/29273.html</link>
		<guid>http://tc.eserver.org/29273.html</guid>
		<description>Writers of English have choices. Most every word we commit to paper (or its electronic equivalent) has a synonym</description>
	</item>
	<item>
		<title>A New Look at Infinitives in Business and Technical Writing</title>
		<link>http://tc.eserver.org/29074.html</link>
		<guid>http://tc.eserver.org/29074.html</guid>
		<description>This article begins by arguing that the infinitive phrase has not been taken seriously in writing because writers have been too concerned with Bishop Robert Lowth&apos;s proscription against the split infinitive. However, careful examination of three types of technical prose (instructions, annual reports, and &apos;junk mail&apos;) reveals that more than one sentence in four contains an infinitive phrase. The article then argues that two linguistic theories do not adequately explain the overwhelming presence of infinitives in the three types of prose. The reason for the presence of infinitives seems to be that they fulfill several rhetorical purposes, including vigor, symmetry, emphasis, variety, economy, and depersonalization. Implications for writing and teaching are also discussed.</description>
	</item>
	<item>
		<title>&quot;Unattached&quot; Clauses in Technical Writing</title>
		<link>http://tc.eserver.org/29011.html</link>
		<guid>http://tc.eserver.org/29011.html</guid>
		<description>The views concerning &quot;dangling participles&quot; of grammarians, usage experts and authors of books on technical writing are reviewed and compared. Although many unattached clauses are clearly unacceptable, some are less objectionable and still others are acceptable practice. Absolute constructions and other clause-relational participial, infinitival and verbless clauses need no attachment to a proximate noun or noun phrase, and logical clauses that are not attached to a noun are shown as normal, acceptable use. Even clearly adjectival clauses are often unattached when followed by the passive voice, intransitives and several other grammatical structures; clauses between the subject and verb and at the end of the sentence are also often not attached to the immediately preceding noun. Cultural (perhaps also gender) differences between humanistic teachers and task-oriented engineers are noted as possible causes of different viewpoints regarding the use of unattached participles, and greater acceptance of the many acceptable forms of unattached clauses is argued. &amp;lt;em&amp;gt;Suggested Reading Approach&amp;lt;/em&amp;gt; The first three sections (on principles, authoritative views and theoretical background) could be skimmed if you are already familiar with the background.</description>
	</item>
	<item>
		<title>It&apos;s All Relative</title>
		<link>http://tc.eserver.org/28635.html</link>
		<guid>http://tc.eserver.org/28635.html</guid>
		<description>When it comes to relative pronouns, incomplete knowledge may lead to frustration and confusion. The pronouns that, which, who, and what serve as relative pronouns when they introduce a relative (or subordinate) clause.</description>
	</item>
	<item>
		<title>Dangling for Position</title>
		<link>http://tc.eserver.org/28156.html</link>
		<guid>http://tc.eserver.org/28156.html</guid>
		<description>Dangling modifiers can be humorous for the reader, but humiliating for the writer. They&apos;re insidious, creeping into our prose and undermining our sentence structure. But they&apos;re easy to find if you know what to look for.</description>
	</item>
	<item>
		<title>Double Take</title>
		<link>http://tc.eserver.org/28157.html</link>
		<guid>http://tc.eserver.org/28157.html</guid>
		<description>If you write documentation for products that can be dangerous if misused, ambiguity is scarier than rush hour traffic on I-40. If you already know what the sentence means, it&apos;s difficult to perceive that it could be taken to mean something else. By stringently applying rules of grammar, you help eliminate potential ambiguity even when you don&apos;t perceive it. Technical content is difficult enough to navigate; give the reader a clear path so he can focus on the journey instead of the road.</description>
	</item>
	<item>
		<title>The Humble Hyphen</title>
		<link>http://tc.eserver.org/28161.html</link>
		<guid>http://tc.eserver.org/28161.html</guid>
		<description>The hyphen serves a single function. It joins things together: syllables of a word separated at the end of a line; two words used as a compound; or a modifier and the word it describes (when the combination itself is used as a modifier). But for the latter two functions, a hyphen isn&apos;t always needed. So how do you decide?</description>
	</item>
	<item>
		<title>Squiggles</title>
		<link>http://tc.eserver.org/28165.html</link>
		<guid>http://tc.eserver.org/28165.html</guid>
		<description>Thomas Mann described the writer as somebody for whom writing is more difficult than it is for other people. Nowhere is this truer than for comma use: while most folks float along blithely putting commas in or leaving them out at whim, we agonize over every squiggle. Why? Because we understand that the presence or absence of a comma can change the meaning of a sentence. In our line of work, unclear sentences can have dire consequences for our readers. So we worry.</description>
	</item>
	<item>
		<title>The Wicked Which and Other Fairytales</title>
		<link>http://tc.eserver.org/28167.html</link>
		<guid>http://tc.eserver.org/28167.html</guid>
		<description>Popular culture is filled with myths about grammar. Taught by generations of English teachers, these stories admonish little children to cling to the straight and narrow path, rather than venturing into the woods of creative communication. Some of these stories are usage guidelines rather than rules, but others are pure fantasy, the flight of some pedagogue&apos;s imagination.</description>
	</item>
	<item>
		<title>Write Right</title>
		<link>http://tc.eserver.org/28169.html</link>
		<guid>http://tc.eserver.org/28169.html</guid>
		<description>When you scan job postings for technical communicators, you&apos;ll find prospective employers seeking candidates who have an understanding of current technology, working knowledge of publishing tools, and time management skills. A bullet may ask for &apos;excellent writing and editing skills,&apos; but that bullet rarely appears at the top of the list. Not for me.</description>
	</item>
	<item>
		<title>Writing Technical Specifications in the Present</title>
		<link>http://tc.eserver.org/27448.html</link>
		<guid>http://tc.eserver.org/27448.html</guid>
		<description>Technical specifications are improved in several ways with one easy procedure - writing them in the present tense. That is, rather than trying to specify constraints on a product that does not yet exist, describe the product as though it already existed.</description>
	</item>
	<item>
		<title>Fear Not the Long Sentence</title>
		<link>http://tc.eserver.org/27365.html</link>
		<guid>http://tc.eserver.org/27365.html</guid>
		<description>Everyone fears the long sentence. Editors fear it. Readers fear it. Most of all, writers fear it. Even I fear it. But...</description>
	</item>
	<item>
		<title>Control the Pace</title>
		<link>http://tc.eserver.org/27339.html</link>
		<guid>http://tc.eserver.org/27339.html</guid>
		<description>Control the pace of the story by varying sentence length.</description>
	</item>
	<item>
		<title>Period As a Stop Sign</title>
		<link>http://tc.eserver.org/27331.html</link>
		<guid>http://tc.eserver.org/27331.html</guid>
		<description>Place strong words at the beginning of sentences and paragraphs, and at the end. The period acts as a stop sign. Any word next to the period says, &apos;Look at me.&apos;</description>
	</item>
	<item>
		<title>Tech Writers, Grammar, and the Prescriptive Attitude</title>
		<link>http://tc.eserver.org/26615.html</link>
		<guid>http://tc.eserver.org/26615.html</guid>
		<description>Many tech writers do not see grammar as a set of conventions to help them write clearly. Instead, to judge by the wording of the questions and responses, they see grammar as a set of unchanging rules that can provide definitive answers in every situation.</description>
	</item>
	<item>
		<title>The Not-So-Able able</title>
		<link>http://tc.eserver.org/26502.html</link>
		<guid>http://tc.eserver.org/26502.html</guid>
		<description>The suffix -able can be very useful in the English language because it helps us to express capability or worthiness. However, it&apos;s often bad form to pick any verb, slap -able on the end of it, and try to make a valid adjective.</description>
	</item>
	<item>
		<title>Punctuation, Punctuation, Punctuation</title>
		<link>http://tc.eserver.org/26276.html</link>
		<guid>http://tc.eserver.org/26276.html</guid>
		<description>A light touch with punctuation has always made sense, whether you&apos;re scratching out a sonnet on velum with a quill pen, or texting a mate on your mobile. It&apos;s meant to enhance communication, not hinder it.</description>
	</item>
	<item>
		<title>Dodge the Grammar Traps</title>
		<link>http://tc.eserver.org/26151.html</link>
		<guid>http://tc.eserver.org/26151.html</guid>
		<description>You don&apos;t have to swallow a grammar book to write correctly. If you can just avoid ten serious and very common traps, your chances of making a grammar mistake drop dramatically.</description>
	</item>
	<item>
		<title>Sentence Types and Sentence Structures Revisited</title>
		<link>http://tc.eserver.org/26067.html</link>
		<guid>http://tc.eserver.org/26067.html</guid>
		<description>Before we discuss sentence types and structures, let us regard writing as a donut. When talking of sentence types, we will consider four building blocks of the donut.</description>
	</item>
	<item>
		<title>Grammar Stammer</title>
		<link>http://tc.eserver.org/22691.html</link>
		<guid>http://tc.eserver.org/22691.html</guid>
		<description>Don&apos;t you think that it is a tragedy that 95 percent of the people who desire to be technical writers have a poor command over the language? I am sure all of us make a mistake or two, once in a while. But to make it in every sentence and paragraph shows utter disrespect for readers.</description>
	</item>
	<item>
		<title>One Hundred Simple Tech Writing Errors</title>
		<link>http://tc.eserver.org/22687.html</link>
		<guid>http://tc.eserver.org/22687.html</guid>
		<description>Here are the 100 writing errors that the author has encountered in his experience. (Followed by the subsequent article &apos;&lt;a href=&quot;http://tc.eserver.org/22688.html&quot;&gt;Ten More Errors in Technical Writing&lt;/a&gt;.&apos;)</description>
	</item>
	<item>
		<title>Ten More Errors in Technical Writing</title>
		<link>http://tc.eserver.org/22688.html</link>
		<guid>http://tc.eserver.org/22688.html</guid>
		<description>So, well, here are 10 more errors. This time we will focus on grammar and punctuation. Most of these are simplistic and obvious. But then they are too common. As usual, I have slipped in some content for the advanced writers too. (This article is a follow-up to &apos;&lt;a href=&quot;http://tc.eserver.org/22687.html&quot;&gt;One Hundred Simple Tech Writing Errors&#xD;&lt;/a&gt;.)</description>
	</item>
	<item>
		<title>Stressing What is Important in a Sentence</title>
		<link>http://tc.eserver.org/22131.html</link>
		<guid>http://tc.eserver.org/22131.html</guid>
		<description>In addition to expunging the usual collection of wordy phrases from documents, editors commonly attempt to tighten up writing to make it more direct, clear, and concise. For example, when editing business and technical material, I frequently change sentences containing &apos;it is,&apos; &apos;there is,&apos; and &apos;there are.&apos; Writers often ask me &apos;what was wrong with that sentence?&apos; I reply that although the sentence wasn&apos;t wrong grammatically, such phrases distract the reader from the important part of the message.</description>
	</item>
	<item>
		<title>Use of Hyphens</title>
		<link>http://tc.eserver.org/22134.html</link>
		<guid>http://tc.eserver.org/22134.html</guid>
		<description>This page collects a series of notes from readers of my newsletter, and my responses to those notes, arising from an article in &lt;A HREF=&quot;http://www.jeanweber.com/news/tenews60.htm&quot;&gt;issue 60, 13 May 2002&lt;/A&gt;. I thank those who took the time to write and explain &lt;i&gt;why&lt;/i&gt; some hyphen usage is considered to be correct or incorrect.</description>
	</item>
	<item>
		<title>Appearing for Sentence</title>
		<link>http://tc.eserver.org/20465.html</link>
		<guid>http://tc.eserver.org/20465.html</guid>
		<description>Commas, semi-colons and colons are the sentence tidiers. Used correctly, they&apos;ll give your written language the &apos;punctuation&apos; that pauses, voice modulations and gestures provide when you speak.</description>
	</item>
	<item>
		<title>Caught in the Active</title>
		<link>http://tc.eserver.org/20471.html</link>
		<guid>http://tc.eserver.org/20471.html</guid>
		<description>Have you been told, perhaps by your computerised grammar checker, that too many of your sentences are passive? Have you heard the rule of thumb that at least 80 percent of the sentences in any passage should be active? If you&apos;ve had the problem or heard the rule, and wonder what the terms active and passive mean, and why one is good and the other frowned on, this article is for you.</description>
	</item>
	<item>
		<title>The Passive in Technical and Scientific Writing</title>
		<link>http://tc.eserver.org/18980.html</link>
		<guid>http://tc.eserver.org/18980.html</guid>
		<description>Almost every discussion of technical or scientific style mentions the passive voice, usually as a stylistic evil to avoid. While I doubt that many of us would endorse such extreme prescriptions as &apos;Always use the active voice,&apos; or &apos;A writer will almost automatically improve his style when he shifts from passive to active constructions,&apos; we may be more ready to accept Freedman&apos;s position in &apos;The Seven Sins of Technical Writing.&apos; His Sin 6 is &apos;the Deadly Passive, or, better, deadening passive; it takes the life out of writing, making everything impersonal, eternal, remote and dead, but he adds that &apos;frequently, of course, the passive is not a sin and not deadly, for there simply is no active agent and the material must be put impersonally.&apos;</description>
	</item>
	<item>
		<title>Breaking the Rules</title>
		<link>http://tc.eserver.org/13554.html</link>
		<guid>http://tc.eserver.org/13554.html</guid>
		<description>In our early writing years, many of&#xD;us toiled under strict teachers who&#xD;drilled the rules of English grammar&#xD;into our collective consciousness.&#xD;We sweated drops of blood on our&#xD;pristine paper as we tried to craft perfect&#xD;sentences for that much-desired &apos;A.&apos; We&#xD;prayed that we didn’t leave a word or&#xD;clause misplaced or dangling for the&#xD;teacher’s angry red pen to mark.&#xD;Yet pick up a work of modern fiction,&#xD;and you might notice that the writer has&#xD;broken many of the rules that were&#xD;drummed into our impressionable heads.&#xD;These days, fiction often resembles the&#xD;casual style of postmodern poetry, with&#xD;sentence fragments and punctuation&#xD;sprinkled about like seasoning. But in&#xD;technical communication, we can’t be so&#xD;casual. We must adhere to those rules of&#xD;grammar our English teachers upheld—&#xD;at least, for the most part.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Writing/Grammar.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>