Hi Sebastian, Syd
Both solutions are basically the same thing as they are based both in
determining the elements that need to be placed outside of p and iterate
on them and enclose the content between them, if exists, in p tags.
There are a couple of differences as I assumed as known the elements
that can go inside p while Syd's/Jeni's solution assumes as known the
elements that cannot appear inside p.
The main issue is to determine the content inside p that should stay
there while the current node is an element that cannot be placed inside
p. It is easy to obtain the preceding element that cannot be placed
inside p as one can just walk on the preceding-sibling axes and get the
first such element, precedingNonInP in my stylesheet. Then basically you
have two elements that are both children of a node and you need to get
the content between them.
In the above sample for instance we need to determine the nodes between
fromHere and toHere knowing both fromHere and toHere.
I determined that walking from the fromHere on the following-sibling
axes, that is testing
and the test checks that the first preceding sibling that cannot be
present inside p is the node we started from, fromHere. The toHere node
also pass this test so I added another check to exclude also the toHere
node that is what the current() funtion returns.
The same idea is in Jeni's code but that walks in the other direction,
from toHere to fromHere in the above example. $before-me points to
fromHere and the current node is also toHere. The nodes that are tested
are the preceding siblings of the current node, that is:
and the test checks that the first preceding in:list or in:eg sibling is
fromHere. It may be the case that $before-me does not select anything
and in that case we want to take all nodes preceding the current node,
that is accomplished by not($before-me). Here it is the expression:
I hope the above explanations help,
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
Sebastian Rahtz wrote:
> George Cristian Bina wrote:
>> Here it is the full solution to correct invalid XHTML p tags. It also
>> accumulates the largest amount of text and tags that can be enclosed in
>> a p element. For instance the following invalid XHTML
> wow. another awesome bit of code. I've never seen anyone use an entity
> like that in XSLT.
> Now I'm torn between your method and Syd/Jeni's stuff!