[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Recommendations for "page break" requests?
> -----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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]