OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]