This is a tricky problem.
There may be more than one way of going about it, but I'd suggest something
like the following:
<!-- assures that nothing wrapped in a filter element
will appear in output -->
<!-- creates a ul when the first bullet in a series of bullets is
processed, and populates it with the bullet and subsequent
immediately-following bullets -->
llet) and not(self::filter)][position() > position(current())]]"/>
Or this is the direction I'd work in, in any case. Note I haven't tested
this, so it's almost sure to break -- but I think the logic should be close.
The XPath would be much easier if there weren't the possibility of more
than one list inside a para. A simpler solution (or one that hides the
complexity, anyway) _might_ be possible using keys (key each bullet to the
proper first bullet of its list).
As you have ascertained, the problem wouldn't arise if you had a list
wrapper element: by far the best solution is to convince the writers that
it's worthwhile putting in ul-style elements for your sake. (And ultimately
for their own: what happens when they want numbers? easy to tag with a
wrapper, a pain without.) After all, why should they bother putting in
<para> tags either? (Answer: so the computer doesn't have to be as smart as
they are. :-)
Hope this helps. Incidentally, this is a good question for the XSL-List
NB: <filter condition>...</filter> is not well-formed, but you probably
already know that.
At 07:40 AM 9/21/00 -0500, you wrote:
>We have an application that needs to generate html from xml input using
>xslt. It is mostly straightforward, but there is a twist that has currently
>been solved with an ugly two-pass approach. Is there a better way?
>Consider something like this
>In other words, a bulleted list in a document but with arbitrary portions of
>the document possibly excluded by a filtering mechanism. In order to
>generate html, the first instance of the bullet element has to generate <ul>
>and the last </ul> in addition to <li>. But whether a bullet element is
>first or last depends on the filter. The current implementation first
>processes the whole document for filter selection and then passes it again
>to produce the list logic. Can this be done in one pass? The writers see
>no need to create an extra element level to specify the list itself as they
>have no other use for this structure.
Wendell Piez mailto:[log in to unmask]
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML