I was lazy and didn't want to reinvent the wheel, so I took DOCBOOK and modified the EDD to make it format the way we wanted. Of course with heading resetting the numbering system I wanted an automatic way to apply the heading formats without reverting to manually setting attributes.
I accomplished this with the recursive sections available in DOCBOOK. So the context of Title element in levels of Section elements works. The context is: If context is: {first} < Section If context is: Section < Section < Section < Section < Chapter Use paragraph format: Heading 4 Else, if context is: Section < Section < Section < Chapter Use paragraph format: Heading 3 Else, if context is: Section < Section < Section < Article Use paragraph format: Heading 4 Else, if context is: Section < Section < Chapter Use paragraph format: Heading 2 Else, if context is: Section < Section < Article Use paragraph format: Heading 3 Else, if context is: Section < Chapter Use paragraph format: Heading 1 Else, if context is: Section < Article Use paragraph format: Heading 2 Context, level they all work well. Scott Chris Despopoulos wrote: > I thought the idea was to format via the EDD, only. Users should never > just apply pgf formatting, because it will get lost (as you describe). > Structure demands template dictatorship on steroids... Or rather, it > imposes it. To add new pgf formats, and to set up users to apply them, > you would have to: > * Create the new formats > * Modify the EDD and the XML to include attribu.tes > * Use the attributes to set the current formatting for the given *element* > * Modify the EDD to set up format rules that map your formats to the > attribute vals > * Store all the above in the template > > In theory, you could create an attribute that is a list of values, and > each value is the name of a pgf format. Then you set up format rules for > every pgf-level element to apply the format that matches the attribute > value. Then do the same for char, table, and other formats??? But this > kind of defeats the purpose of structure. The idea with structure is (as > has already been said) to separate structure from display. You want a > machine to make the display decisions at the last minute. And FrameMaker > is just one such machine. By using that principle, then you can automate > great things, like if you move a section to become a sub-section, all > the formatting adjusts automatically. > > I'm sure you know all this, but maybe you need to remind the customer. > Or maybe you need to interpret the customer request as a symptom that > the EDD/DTD is not sufficiently specified for their project. Maybe it's > time to address more fundamental issues? >