Editor's Note

There’s A Word For That...

This month in MSDN Magazine, we are looking at the world of Web services. But before we tell you all about this month's issue, we have a topic we would like to address. In fact, it's our civic duty to do so.

Here in the magazine's offices, we editors have more than a passing familiarity with the world of the programmer. It's this experience that gives us the right—nay, duty—to speak out. We realize that a lecture may make us seem "square" or "uncool" in the eyes of some developers, but it's time to take our position of self-appointed responsibility and use it for everyone's benefit. Our request is simple and to the point: please, for the love of all that's good in this world, stop making up words.

We realize that invented verbiage is not a new phenomenon in the world of the developer. Some new words may, in limited circumstances, be okay. In fact, there are three classifications of invented English that we run across, two of which are acceptable.

  1. Words that are invented or adapted to describe new programming techniques. When you talk about boxing and unboxing a value, it's actually the adaptation of an existing word to describe something for which there was no previous word. Similarly, the world of design patterns is rife with descriptive words like "factory" that make sense in their new surroundings.
  2. Words that are created as slang. True, these can sound forced and cloying. But when cyberspace has worn you out, you can always go back to your life in meatspace—it's colorfully descriptive, not a buzzkill at all.
  3. Words that represent the wholesale butchering of the English language. This is the problem we're addressing here.

We are asking for your help in eradicating words that have been invented for no good reason. Sometimes, it's too late to do anything about them. Look at the word "canonicalize," for instance. It is used to mean "to create the canonical form" of something, like a URL (as in InternetCanonicalizeUrl from the WinINet API). It's not English; it was invented because someone didn't know that there was already a perfectly adequate word for this process: "canonize." However, once this non-word has been created, the rules of the language suddenly apply again, so the process of "canonicalizing" something is "canonicalization" instead of "canonization."

More recently, we've seen the word "performant" start its crawl into the everyday vocabulary of devspace. It is used to mean "highly performing." It's also not a word. When something provides information, it's informative. It's not "informant." The word "performant," if it existed, would be a noun—not an adjective. But it doesn't exist, so if you do see it in print, remember that it's not really there.

Any readers who have made it this far are probably rolling their eyes now, thinking to themselves, "Why are they being such sticklers here? Isn't the language a wonderful, evolving thing?" Yes, our language is evolving. As there is a need for new words, new words enter the language. But making up new words is just as bad as using fancy words in place of short ones. Why say "This project's goals are orthogonal to the company's needs"? Admit it—if you were at home, you'd just say "different from" or "at odds with."

Or should we just give up and start inventing our own language? We could always be goaled to introduce our own efficiencisms into code samples for the purposing of improvating the downloadicant experience for our readers. Then we can get back to work with the manuscriptive process, making sure that the articles in the magazine are exactitudinally microcoded for perfectant reading. What's the problem? You can figure out what those words all mean!

Now that we're all in agreement, let's talk Web services. This month's issue brings a spring bouquet of articles that will give you some cool ideas for enhancing your Web services. If you want to combine the data from more than one Web service for maximant efficiencisms in your code, Gerrard Lindsay explains how WSDL is the way to do it. If you want fine-grained control over the XML of which your Web service is emittive, Chris Dix takes a look at message control with WSE 2.0. We even take a look at BPEL4WS and how it is interactionate with BizTalk Server 2004.

So polish up your Web services, drop us a line , and stop making up words. We are behoovant of you.


Thanks to  the following Microsoft technical experts for their help with this issue: Mark Boulter, Israel Burman, Tom Christian, Rebecca Dias, Kedar Dubhashi, Brian Grunkemeyer, Jonathan Keljo, Martyn Lovell, John Nisi, Polita Paulus, Riyaz Pishori, Matt Powell, Mark Novak, Eric Richards, Scott Robinson, Yasser Shohoud, Chandu Thota, and Cathy Wissink.

Active Directory, ActiveX, BizTalk, InfoPath, JScript, Microsoft, MSDN, MS-DOS, SharePoint, Visio, Visual Basic, Visual C++, Visual C#, Visual Studio, Windows, Windows NT, Win32, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation. Other trademarks or tradenames mentioned herein are the property of their respective owners.

MSDN Magazine does not make any representation or warranty, express or implied with respect to any code or other information herein. MSDN Magazine disclaims any liability whatsoever for any use of such code or other information.