Spend some time dreaming up doomsday scenarios. Pretend you’re in some Pentagon war room, deep beneath the ground surface, plotting your contingency plans and inventing your counter reactions. The more flexibility you can build into your definition, the better you will be.

Mistakes and Redefining Your Environment

Even after all this, you’ll probably still make some mistakes. But, if you’ve done all the work described above, the damage is likely to be repairable. If you’ve taken shortcuts, your risk of having problems is higher; so is the risk that your problem is farther reaching.

---

Note:  
The way you decide whether your oversight is big or small is by how much it changes what you’ve done to date.

---

Some examples of major problems that can occur are:

•  Major types of documents have been overlooked

•  Fundamental types of information—critical to just a few customers at certain times of the year—have not been accounted for

•  Several types of documents are actually the same, but somehow have been confused as being different

•  Some commonplace tool that affects all employees and all documents has not been accounted for (like a peculiar network server or archaic mainframe that produces data in rigid and strange formats, but that everybody must use anyway)

•  Your company is being acquired by another company

•  Your department is being merged with another department

•  A new industry-wide standard is being adopted that will affect every piece of information your department distributes

•  You forget to indicate which documents might get translated to foreign languages (and which foreign languages)

•  Some catastrophe happens, and you must restore all your data from tape (or other) backups—and you forgot that your data is backed up before it is tagged with SGML

•  Your company must move to a different state, and you have no provision for how the data will be transported

•  You forgot to talk with some group of people in your department who were responsible for a realm of documents you overlooked.

The list could go on. But when something does go wrong, decide whether it’s a major or minor problem.

Assessing Damage Impact

You know the damage is big when someone asks, “Did I forget to mention that Mr. Shmagmotz, the president of the corporation, wants every field of the company database to be translated into New Swedish?” and everyone in the room just stares at the person asking the question. Something like this could possibly cause you to start all over again.

Translating your documents into another language was already covered immediately above. So if you asked these questions, you would not have been surprised by Mr. Shmagmotz’s predilection for New Swedish.

Usually, big problems mean you have to start over considering a new group of document types that you didn’t know existed. Then you have to hold up your progress on the rest of your older documents while you go through all the steps with those newer documents. If you run into something that changes the way you look at all your types of documents, that is a mistake that causes a big impact.

Fixing Big Mistakes

Suppose somebody makes a mistake, and it looks as though you have to start the whole process over from scratch. You have a choice:

•  Take a recess and let your coworkers collect themselves—talk about it again after coffee today. Maybe it’s not a problem after all.

•  Finish up what little business you have for the day. Withhold further discussion on the problem until tomorrow. Perhaps a day later the problem won’t appear so nasty.

•  Assign people to research the problem to see if there are related facts that could lead to a solution. Get the facts.

•  Ignore the problem for now; maybe you’ll find a way around it. (Give yourself a time limit or dollar limit on this.)

•  Just start over. Salvage what you can from what you’ve done. Discard the rest. Chalk it up as a learning experience.

How to Know When You’re Done Defining Your Environment

You may never know if you’re done defining your environment. But the proof, at least for now, is: does everything work? You won’t know this until you’re in production mode and have been for at least six months. Larger operations require a longer testing period. If your department has 40 people, and you publish 20 books per month, you might easily need two years of testing. It might take you that long to get the bugs worked out of all your different types of tools and customer connections and relationships.

If you went through all the steps described above, you did about as much as anyone can do. When you do find that you need to make a change in how you’ve defined your whole “universe” of documents, go and make the change. But make it carefully. You could easily confuse everything you have done so far if you change something haphazardly. Be careful!

Two years later, if you’ve had basically painless production and your employees and customers are happy about your endeavor, then you are done…for now.

From Here…

Defining your environment takes you through the process of matching your aspirations for an SGML enterprise with the realities of your current ways of doing business. This process forces you to isolate inconsistencies and resolve them. It’s the first step of document analysis because there’s no point of defining your document elements if you have serious conflicts between your policies and your aspirations. You have to take care of first things first.

Besides defining your environment, other chapters round out the document analysis task:

•  Chapter 7, “Defining the Elements,” takes you a step further in dismantling your documents to their basic components. You’ll understand the bones of their structure at the end of this chapter.

•  Chapter 8, “Relating Elements to Each Other,” teaches you how to make the elements you identified in Chapter 7 all work together harmoniously.

•  Chapter 9, “Extending Document Architecture,” teaches you how to make your collection of elements richer and fuller.

•  Part III, “Content Modeling: Developing the DTD,” takes you into preparing the DTDs for all your document types.

•  Chapter 23, “Rapid Development and Prototyping,” takes you into an advanced situation applying the basic principles learned in this chapter to a real world professional example.