RE: [dita] Recommendations for "page break" requests?

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Paul and other esteemed DITA OASIS citizens:

I'm wondering if a CSS-like strategy could work -- not necessarily doing anything with the properties provided by CSS but, instead, using a similar approach.

That is, could an output policy file that's separate from the DITA content files specify selectors to attach properties (such as the widow and orphan controls suggested by Rob) to elements? Such policies would make it possible to create thoughtful designs and apply:

* A single design to content in multiple deliverables for consistent presentation.
* Different designs to the same deliverable to produce presentation for different purposes.

If instead presentation hints are embedded in the content,

* You'd need to distinguish hints for different presentations (which could turn into presentation spaghetti).
* The content file has to be modified to change the presentation.

Where you have a workflow where content changes trigger editing and translation, you might prefer to update your files only when the content changes.

In CSS, selectors provide the ability to select content instances by element type, class, or id and other attributes and to nest such selectors for contextual selection.

Because specialization supports element extension and inheritance, selection by element type would become much more powerful in DITA than in a fixed vocabulary like HTML. In addition, DITA supports informal semantics similar to the HTML class attribute through the outputclass attribute.

A possible example:

<printPolicy>
 <!-- emit a page break before appendix, chapter, and preface topics in a bookmap -->
 <element classes="appendix chapter preface">
   <pageBreakBeforeProperty/>
 </element>
</printPolicy>

This policy-based approach would require an XML vocabulary for specifying selectors and properties.  The set of supported properties would be dependent on the process and its capabilities.  A page break property, for instance, might be available for print output but not for online output.  The supported properties might be very specific to the processing toolchain of the organization.  In fact, some processes could accept properties unrelated to presentation.  

To extend or restrict the set of properties for a different kind of process, the policy vocabulary could support specialization of selectors and properties.  (An example of a specialized vocabulary that would be separate from the DITA topic type hierarchy.)

Such policies would be limited by comparison with XSLT but would have a different role in the processing story because they could be easily edited with property-based dialogs or by-example design tools and thus could created and modified by designers instead of by programmers using code editors.

In summary, ad hoc presentation tweaks like line breaks and page breaks would be more difficult than with inline elements or processing instructions, but presentation policies would be much easier to implement.


What do you think?


Erik Hennum
ehennum@us.ibm.com


"Paul Grosso" <pgrosso@arbortext.com> wrote on 09/17/2004 08:52:34 AM:

>  
> Don says, on the one hand, this can't easily be put into
> a stylesheet, but on the other hand that direct mods in
> the source are harmful.
>  
> Either PIs (with which I have no problem--we're talking
> about processing, after all) or source elements are direct
> mods in the source.  No use arguing between those choices
> if we don't want direct mods in the source.
>  
> If you don't want direct mods in the source, then you're
> talking about a stylesheet in one way or the other.  Maybe
> it's a special "linebreak/pagebreak exception file" rather
> than an official XSL-FO stylesheet, but it's still a stylesheet
> in the general sense.  I could theoretically imagine making 
> something like this work via an XPath that points to where 
> the break should be, but I suspect this would get too
> complicated in practice.
>  
> So if we don't want direct mods in the source and we don't
> want a stylesheet, what's the alternative that I'm missing?
>  
> My preference right now is to use PIs because I think 
> something in the source is the only practical way to go, we 
> are taking about instructing the processing of the document, 
> and because making them a PI instead of an element makes it 
> easier to toss them from any "database" since you probably 
> don't want to store such info in a topic permanently.
>  
> paul
> 
> From: Don Day [mailto:dond@us.ibm.com] 
> Sent: Thursday, 2004 September 16 17:17
> To: DITA TC list 
> Subject: [dita] Recommendations for "page break" requests?

> Yes, I know the mantra, "XML promises separation of presentation 
> from content." Yet our users still ask for page breaks, line breaks,
> and other presentational nudges that just can't be separated easily 
> into a stylesheet.
> 
> Processing Instructions and other direct mods in a source topic are 
> considered harmful; if the topic is reused elsewhere, the 
> instruction could cause mischief.
> 
> So while this is a general question, it still has bearing on work we
> might do down the road on a recommended style mechanism for DITA:
> 
> >>>> For page and line breaks in particular, what do you do, and 
> what do you recommend? 
>  
>