Re: EDD Format Design Approaches [A REAL-WORLD SITUATION]

[DW Emory <danemory@xxxxxxxxxxxxxxxxxx>]

Hedley:
My paper, "A New Approach to Single-Sourcing", available on the microtype 
website (www.microtype.com) under New/Updated Items, offers a number of 
structured document solutions that might be applicable to your 
requirements, particularly the solution to the conditional text problem.

Although not mentioned in that paper, a couple of choice-type attributes in 
elements valid at the highest level could (using an Approach 3 methodology 
for developing the EDD) easily automate the format variations which are a 
function of different sizes/fonts/styles required for the deliverables in 
different markets. That is, the applicable EDD format rules (and associated 
format change lists) would be determined by the values of those attributes 
in each element context. Simply changing the values of those attributes 
would automatically re-format the document for the desired deliverable.

This approach would eliminate what must currently be the nightmare of 
maintaining a separate template (with different 
paragraph/character  formats) for each deliverable. Instead, those 
templates would now simply be used to change the page size/master pages 
(and any other parameters not controlled by the EDD) for each size/layout 
combination.

Admittedly, the solution to the format variation problem described above 
does not solve the problem of producing on-line help if your conversion 
method employs a paragraph mapping algorithm such as that used by WWP. An 
XSL/XSLT solution for producing on-line help would, however, be completely 
compatible with the EDD design approach described above. Alternatively, if 
your on-line help conversion tool does use a paragraph mapping algorithm, 
you could develop an Approach 1 version of the same EDD (in which the 
structure rules are the same as the Approach 3 EDD, but the format rules 
specify different paragraph/character tags for each context variation of 
each element). This will allow you to map each paragraph tag to the 
corresponding element in the on-line help structure. You then create a 
template for this Approach 3 EDD by importing the element definitions into 
the template. Then, in that template, format each tag so that it minimally 
contains the formatting information required for producing the style sheet 
for the converted output. Finally, you import the element definitions and 
formats from the template into the document to be converted to on-line 
help, which prepares it for conversion.

Needless to say, the conversion of your unstructured documents to 
structured ones could be quite daunting task using FrameMaker's Conversion 
Table methodology. However, if your existing documents are consistently 
tagged, and those tags make it possible to distinguish (at least in a 
majority of cases) between different elements in the target structure, it's 
probably doable by developing and applying structure rules tables, followed 
by some manual cleanup. The unstructured-to-structured methodology I 
advocate involves the following steps:

1. Develop the "real" EDD, using the Approach 3 methodology.
2. Develop a conversion EDD, which, to the extent possible, uses the same 
element names and structure rules as the "real" EDD. This conversion EDD is 
designed to optimize the mapping of the existing paragraph tags to the 
corresponding elements in that EDD. In a bare-bones approach, this EDD does 
not even require any format rules. In cases where the existing tags cannot 
be conclusively mapped to a single element (e.g., a one-to-many 
relationship exists between the tag and the elements it might map to), you 
define an element whose name (which differs from any element name in the 
"real" EDD) identifies this ambiguity.
3. Develop the conversion tables for the conversion EDD, and apply them to 
the unstructured document.
4. Import into the structured document produced in step 3 the element 
definitions from a template created by the conversion EDD, and validate the 
structure. Undoubtedly, anomalies will be found. Make the corrections 
needed to make the document a valid instance of the conversion EDD. Most 
such corrections are accomplished by using the Wrap, Unwrap, and Change 
actions on selected elements in the structure view.
5. Import the element definitions from a template created by the "real" EDD 
(this template should contain formatted versions of all the 
paragraph/character tags defined in that EDD), and re-validate the 
structure. More anomalies will be found. Correct them so that the document 
is a valid, properly formatted instance of the "real" EDD. Again, most 
corrections are accomplished by using the Wrap, Unwrap, and Change actions 
on selected elements in the structure view.

  I offer you, on a consulting basis, my EDD and document conversion skills 
for accomplishing this daunting project.

At 04:32 PM 9/5/03 +1000, hedley_finger@myob.com.au wrote:

>The argument between assigning individual para and char formats to elements
>v. assigning a few para and char formats to 'parent' elements and having
>format differences applied to 'child' elements by format rules continues to
>rage.
>
>So those in both camps might like to consider how their preferred
>approaches stack up against a real-world example.
>
>Consider a family of products which is sold in many markets around the
>world.  Each product is built from a single codebase with switches set for
>feature sets and market peculiarities.  The user guides are single-sourced
>from one fileset.  Some user guides are portrait, others are landscape.
>Some are two-column, others are single-column.  The trim sizes of the user
>guides are different sizes to snugly fit the most economical box size
>dictated by a the postal regulations and freight-charge breaks in each
>market.  The para and char formats use different fonts and styles depending
>on the market.  Oh, did I mention that we also single-source the online
>help?
>
>At the moment the files are unstructured and we use dozens of conditions
>with our own proprietary condition-manager plugin to make them easier to
>work with than FrameMaker's inbuilt conditions management.  We import
>formats to transmogrify the files to suit a particular deliverable.
>
>So now will the proponents of the individual formats v. format rules
>approach explain to me why their preferred approach is to be preferred for
>this scenario?
>
>I know into which camp I would fall!
>
>Regards,
>Hedley
>
>--
>Hedley Finger
>Technical Communications Support Specialist
>MYOB Australia <http://www.myob.com.au/>
>P.O. box 371   Blackburn VIC 3130   Australia
>12 Wesley Court   Tally Ho Business Park   East Burwood VIC 3151
>Australia
><mailto:hedley_finger [at] myob [dot] com [dot] au>
>Tel. +61 3 9222 9992 x 7421,   Mob. (cell) +61 412 461 558
>
>(C) MYOB Limited 2003
>
>
>** To unsubscribe, send a message to majordomo@omsys.com **
>** with "unsubscribe framers" (no quotes) in the body.   **

FrameMaker/FrameMaker+SGML Document Design & Database Publishing
DW Emory <danemory@globalcrossing.net>


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **