Inverted GPL - multiple parents, one child

[PaulC]

We're just getting started with Flare. We've been using FrameMaker and WebWorks to generate PDFs and online help for a suite of 24 image-laden books. As I've been pondering the best structure for these books in Flare, I've theorized a construct that doesn't appear in Flare help or on this board.

Imagine a Global Project Link (GPL) structure where a single child has 24 parent sources:

• Each parent is a holder of content (*.htm, *.png, and a .fltoc) and has a PDF target consisting of one book.
• The child is an organizer of all its parents' content (master TOC, stylesheets, etc.) and has a WebHelp target comprising all 24 books.

As I see it, this approach has a few advantages:

• It provides a single entity for a final master help file that affords unified CSH, TOC, and index.
• It provides multiple entities for PDFs and interim single-book help files.
• It allows several books to be worked on simultaneously without collision. (We won't be using source control until we've settled on a directory structure.)
• It allows for incremental import of FrameMaker files either one or several at a time, with experimentation and mistakes.

There's one big drawback:

• It inverts the intended design of GPL, possibly leading to unenvisioned problems and challenges.

Any thoughts on why this might or might not be a good approach for our situation?
Any suggestions on a better approach?

[KevinDAmery]

I don't see a problem here. You would need to create multiple imports in the child, one for each source project (so it sounds like there would be 24 import setups in your case). Once the content is imported, the work flow is no different than a standard Flare project. I don't think the "drawback" you have listed will prove to be much of a problem when you implement the project.

As to the advantages...

As I see it, this approach has a few advantages:

* It provides a single entity for a final master help file that affords unified CSH, TOC, and index.
* It provides multiple entities for PDFs and interim single-book help files.
* It allows several books to be worked on simultaneously without collision. (We won't be using source control until we've settled on a directory structure.)
* It allows for incremental import of FrameMaker files either one or several at a time, with experimentation and mistakes.

Only the last two points actually benefit from using GPL at all. The first two points could be achieved equally well by using one large project - all you would need is to create TOCs, condition definitions, and output targets for the 24 components that included the relevant topics and excluded the irrelevant topics. GPL is a perfectly rational way to go about what you are describing, but it isn't the only way to do it.