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

["Paul Grosso" <pgrosso@arbortext.com>]

> -----Original Message-----
> From: Paul Antonov [mailto:apg@syntext.com] 
> Sent: Friday, 2004 September 17 12:33
> To: DITA TC list
> Subject: RE: [dita] Recommendations for "page break" requests?
> 
> On Fri, 2004-09-17 at 21:02, Don Day wrote:
> 
> > I'm not finding great possibilities in my searches either. Unicode
> > provides a set of characters that are directives for 
> formatters, but I
> > REALLY don't want writers to learn about that Pandora's 
> box. PIs would
> > be much easier to detect and handle in processing, 
> particularly since
> > they provide an opportunity for conditional use, which a codepoint
> > does not. Oh, I'm not convinced yet, just working up the nerve to
> > accept the idea.
> 
> Are you sure you want to use PI's? 
> 
> - they cannot be validated by Schema or DTD (during the authoring
> process, too)

You don't want to valid them.  They are post-validation overrides.

> - if you want to tweak processing of some element, what you do? Insert
> PI before, after, or inside?

None of the above.  They are part of the processing of an element.
They are an override orthogonal to element content.  For example,
you want to force a line break or page break between two characters 
in character content having nothing to do with element structure.

> Processing attribute in such case is much
> more intuitive, at least with XSLT
> - using attribute or element is easier from the authoring perspective:
> you can define element specialization and enumeration for the value of
> such attribute.

You don't want such control over one-off processing exceptions.
The whole point of these things is that they aren't part of
the information structure--they are "for no good reason, but
I just want to force a break here" things that should not have
the force of elements.

> 
> So let us at least consider alternative approach: having special
> attribute and/or element, with no well-defined semantics, which should
> be ignored by default. 
> 

I agree that would work, and I could live with that, but I don't
agree that this is better than PIs.

paul