This is interesting and impressive stuff, but surely it would make life
easier if we were to conclude that what TEI means by <p> (something
close to the broad typographical paragraph, which allows embedded block
elements) is not the same thing at all as what XHTML means by <p> (the
lowest level textual block element, allowing no block children, and not
equivalent to a typographical paragraph at all). When we render TEI to
XHTML, we're actually doing something which is closer to rendering to
XSL:FO than it is to creating an equivalent conceptual document
structure; the XHTML is basically a rendering representation which
display. It would be impossible to create a realistic rendering of a
complex TEI document in the much simpler XHTML element space, and I
don't think we need to try. If people need to see the "true" structural
representation of the document, they can look at the TEI XML; XHTML is
just a convenience for browser-rendering.
So I think it's perfectly fine to turn <p> tags into <div type="para">,
just as it's OK to turn <note> elements into <div type="PopupNote"> and
George Cristian Bina wrote:
> 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:
> [not($before-me) or
> generate-id(preceding-sibling::node()[self::in:eg or
> self::in:list]) =
> generate-id($before-me)]" />
> 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!
University of Victoria Humanities Computing and Media Centre
([log in to unmask])
Half-Baked Software, Inc.
([log in to unmask])
[log in to unmask]