From: David Tolpin (email@example.com)
Date: Thu Mar 27 2003 - 08:20:02 PST
> Hmm--I'm not sure this solves the problem though, because it may not be
> possible or practical to construct a containing flow object that exactly
> demarcates the start and end of my desired range.
> That is, if I have the sort of "<start-range/> ... <end-range/>" markup
> that one would normally use to specify index ranges in the source, I
> can't think of a way to reliably translate that to a block that exactly
> contains the range--it likely crosses the normal flow object hierarchy
> produced by the non-index input elements.
firstly, I am not sure one would normally use start-range/end-range markup
for index ranges. In my opinion, attaching indices to block structure is a more
natural approach. The fact that current markup practice uses markup ranges
is a reflection of limitations of earlier approaches, not a more natural or
consistent way to specify index ranges.
An index range is connected to an entity related to the index key. Using blocks
for semantic entities is natural. Interspersing block structure with ranges
However, the current model can be extended to handle the 'normal', that is, traditional
markup for index ranges. I'll try to allocate time for that as soon as I get clear
understanding of the problem.
> By the same token, just pushing the rx:key to the parent page-spanning
> block wouldn't always be appropriate because that block might extend
> farther than the intended range. This would be the case, for example,
But will be appropriate in many cases. In cases when it is not appropriate
it is most probably a sign that the data is not structured properly.
If a contiguous range is related to a certain index key, than the range
should probably be a separate supchapter.
A language limitation (as well as in programming language) is not always
an obstacle. Much more often it is a hint and a stimulus to better organize
> when the index range reflects a sequence of paragraphs in a larger
> container, where the sequence of paragraphs is not otherwise identified
> by containment. In this particular case I might be able to synthesize a
> block that contains just those paragraphs, but doing so would seriously
> complicate the XSLT process (because I'd have to check for index ranges
> at the start of every paragraph and then verify that the range didn't
> cross a structural boundary that would result in a structural boundary
That is, XSLT has a limitation that prevents the structured approach currently
implemented in RenderX XEP from using with signle-pass DocBook stylesheets.
I'll think about ways to bypass this limitation of XSLT.
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to firstname.lastname@example.org from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Thu Mar 27 2003 - 08:12:07 PST