Callanish wrote:
The purpose of the document is to enable clients to review software
specifications prior to the changes actually being built. In the past, all
changes were defined in a single spec, but we are in the process of
implementing RUP, which requires separate documents for each component - for
example, a screeen has its own UI prototype document, each process has a use
case document and so on.

We're trying to minimise clients' resistance to this change in their
process. We anticipate that they will (understandbly) be reluctant to review
multiple documents, where previously they would only have had one long
document to consider.

I share your reservations about using document objects, and was hoping to
find a technical reason to veto this approach. That's a good point about
conflicts between different versions, as we don't know precisely which our
clients are using.

In that case, I'd rather consider using a bunch of INCLUDETEXT-fields:
you have all your individual files, and compile one large document for
each client by pointing to the parts with INCLUDETEXT. Best make one
template for each client, so you can open up a new document based on it
and right away unlink the fields. In effect, you have a single document
then, comprised of all the parts.

2cents
Robert
--
/"\ ASCII Ribbon Campaign | MS
\ / | MVP
X Against HTML | for
/ \ in e-mail & news | Word