wrapping elements

Subject: wrapping elements
From: Alan Pagliere <pagliere@xxxxxxxxx>
Date: Fri, 26 Feb 1999 12:28:15 -0500 (EST)
	After looking at some other tools (which we may keep looking
at....) we decided to try to use XSL for some XML transformations. 
	We are trying to use XSL to do some occasionally interesting
transformations. We have some texts that come to us with SGML that is,
shall we say, less than logical. We are trying to transform some of that
SGML into a more standard form, so that our software that deals with SGML
(indexing, accessing, cgi translation to and delivery of HTML) can be more
uniform across texts. 

	(In case you're wondering, getting our wonderfully normalized and
validated SGML into XML is very easy. That is not the problem.)

	So, in order to get closer to a standard (we use most often TEI.2
type markup), we have the need to do some complex transformations.  An
example might be: take certain attributes from an element, pull them out,
wrap them in another element, and make the new element a child of the
	Here is the one we are working on at the moment. It is less
complicated than other things we want to do, so if this is impossible in
XSL, we may have to rethink, regroup and otherwise revamp.

Imagine a stream of elements in the following order:

<DIV> <PB/> blah </DIV> <PB/> ... </DOC>

We want to take any and all epigraphs, arguments, dedicats and prefaces,
however many there be, and "wrap"  them in a FRONT element, so that we

</FRONT> <DIV> blah </DIV> <DIV> <PB/> blah </DIV> <PB/> ... </DOC>

We tried:

  <xsl:if test="./*[first-of-type()]">

hoping against hope that once matched in the template, the xsl:if's test
would treat anything matched by this template as "of a type". That way, we
would spit out a <FRONT> tag before the first of any of them, and then
process children (aka apply-templates).
	We would have a similar one for last-of-type to spit out a closing 
</FRONT> tag.
	Of course, no luck. It kicks out a <FRONT> tag before each of the
first of any of the matched elements.

	Questions: Are we just going about it the wrong way or can it just
not be done? Is there some clever way we just are not seeing?

	Thanks profusely for any insight.

Alan Pagliere
University of Michigan
Digital Library Production Service
308 Hatcher North
Ann Arbor, MI 48104-1205

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread