cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Release management strategy for Dynamic Documents

Level 7

Release management strategy for Dynamic Documents

Description:

I have DITA bookmap with topics (User Manual). I load them to Windchill. I get dynamic documents:

  • DITA bookmap A.1
  • topics...A.1  

Then I publish them to PDF and then print it. I give printed manual to my customer(1).

Then I change topic_1 from this manual:

  • DITA bookmap A.1
  • topic_1 A.2
  • other topics...A.1

Then I republish User Manual to PDF and print it. I give printed manual to another customer(2).
This is another User Manual than have customer(1).
Then customer(I don't know which - 1 or 2) calls to our tech support and says that he finds the error in our User Manual.

 

How to identify which User manual does he mean? How to find it in Windchill?
If I have 1000+ bookmaps, 10000+topics with 100+ versions, 10000+ customers.
My question is about what metadata from Windchill I should use to track my printed documents with their Windchill objects.

 

I only see this way:

Use version attribute of Dynamic Document from Windchill(burst settings) in DITA bookmap  and always iterate root DITA bookmap object when topic is changes. It's hard manual work. For example, if topic is used in 500+ maps.

Are there any another ways?

 

 

 

6 REPLIES 6

Re: Release management strategy for Dynamic Documents

The combination of the Windchill object ID and "version.revision" gives you the unique identifer from a data perspective. If you use the title of the topic or even the topic filename then the problem you have is that the same topic name could be used all over the place (e.g. "Introduction").

Re: Release management strategy for Dynamic Documents

Hi,@GarethOakes

"The combination of the Windchill object ID and "version.revision" gives you the unique identifer from a data perspective." - No. See my description.

I get dynamic documents:

  • DITA bookmap A.1
  • topic_1...A.1  
  • topics..A.1

Then I publish DITA bookmap A.1 to PDF and then print it. I use "version.revision" in PDF(A.1). I give printed manual to my customer(1). 

Then I change topic_1 from this manual:

  • DITA bookmap A.1
  • topic_1 A.2
  • other topics...A.1

Then I republish DITA bookmap A.1 to PDF and print it. I also use "version.revision" in PDF(A.1). I give printed manual to another customer(2).

So my customers have same unique identifers of User Manual (DITA bookmap A.1) with different content (topic_1 A.1 and A.2).

Re: Release management strategy for Dynamic Documents

You misunderstand. The Windchill Object ID is not visible in Arbortext (or is perhaps under the dialogs somewhere?). It is a random ID like "01324512344". It has no relationship to DITA topics, but is the ID used for storage in the underlying database. You can retrieve it and map it to XML attributes using the 2-way bursting rules.

Re: Release management strategy for Dynamic Documents

You can retrieve it and map it to XML attributes using the 2-way bursting rules.

Using this method I get 2 PDFs of DITA Bookmaps with the same identifiers (for example, on the first page) 01324512344_A.1, but with the different content (topic_1).

 

Re: Release management strategy for Dynamic Documents

Right, so don't use the Windchill Object ID of the DITA bookmap, use the Windchill Object ID of each topic (say, printed in the footer). These will be unique. The combination of Windchill Object ID and version.revision gives you the exact source of the content, if that's what you're after.

Re: Release management strategy for Dynamic Documents

Use the Windchill Object ID and version.iteration of each topic (say, printed in the footer) is not a good idea. I haven't seen such manuals.

 

I only see this way:

Use version attribute of Dynamic Document from Windchill(burst settings) in DITA bookmap  and always iterate root DITA bookmap object when topic is changes. It's hard manual work.

 

I think to use baselines. With them I could compare two documents and see the difference. It would be great if I could mapping the information from the baseline to the dynamic documents.But it doesn't support.

 

The modularity of the documentation brings both its pluses and its minuses.

When I use 1 monolithic document, I could completely iterate it (version 1,2...). But the minus is content reuse.

When I use a modular document, I could effective reuse topics. But the problem with changing topics, tracking these changes at the map level and comparing changes with printed documents.