Conflicting templates

[patrik.nyman]

I have this templates to mark up hyphenation over line breaks:

<xsl:template match="reg[@type='hyp']">
<xsl:apply-templates select="@orig"/>
</xsl:template>

<xsl:template match="reg[@type='hyp']/@orig">
<xsl:call-template name="html-hyphens"/>
</xsl:template>

<xsl:template name="html-hyphens">
<xslaram name="w" select="."/>
<xsl:variable name="car"
select="substring-before($w,'|')"/>
<xsl:variable name="cdr"
select="substring-after($w,'|')"/>
<xsl:choose>
<xsl:when test="$cdr">
<xsl:value-of select="concat($car,'-')"/>
<br/>
<xsl:call-template name="html-hyphens">
<xsl:with-param name="w" select="$cdr"/>
</xsl:call-template>
</xsl:when>
<xsltherwise>
<xsl:value-of select="$w"/>
</xsltherwise>
</xsl:choose>
</xsl:template>

I also have this simple template for italic text:

<xsl:template match ="it">
<i><xsl:apply-templates/></i>
</xsl:template>

This works fine if I write something like:

<it><reg type="hyp" orig="Hyphe|nated">Hyphenated</reg></it>

Now I can choose if I want to preserve linebreaks or not.
But as it happens, in some of the texts I'm working on,
sometimes ony part of the word is in italics (or formatted
some other way), like <it>Hyphe</it>nated, and since I
can't do

<reg type="hyp" orig="<it>Hyphe</it>|nated"><it>Hyphe</it>nated</
reg>

I must write something like:

<choice type="hyp">
<orig><it>Hyphe</it>|nated</orig>
<reg><it>Hyphe</it>nated</reg>
</choice>

So for this I added the following templates:

<xsl:template match="choice[@type='hyp']">
<xsl:apply-templates select="./orig"/>
</xsl:template>

<xsl:template match="choice[@type='hyp']/orig">
<xsl:call-template name="html-hyphens"/>
</xsl:template>

But the combination of the <it> and <choose> elements
are not working. Can anyone help me out?

Thanks a lot
/Patrik Nyman

 

[Joseph Kesselman]

I have this templates to mark up hyphenation over line breaks:

I'll try to look at this in more detail later, but... Y'know, this is
the sort of task that I would suggest handling in the redering engine,
rather than at the XML level. The renderer is the level which knows
where line breaks are going to have to be inserted, and is traditionally
where hyphenation is done as a result. That's generally driven by a
dictionary, though it could certainly take advantage of hints in the source.

<xsl:template match="reg[@type='hyp']">
<xsl:apply-templates select="@orig"/>
</xsl:template>

<xsl:template match="reg[@type='hyp']/@orig">
<xsl:call-template name="html-hyphens"/>
</xsl:template>

<xsl:template name="html-hyphens">
<xslaram name="w" select="."/>
<xsl:variable name="car"
select="substring-before($w,'|')"/>
<xsl:variable name="cdr"
select="substring-after($w,'|')"/>
<xsl:choose>
<xsl:when test="$cdr">
<xsl:value-of select="concat($car,'-')"/>
<br/>
<xsl:call-template name="html-hyphens">
<xsl:with-param name="w" select="$cdr"/>
</xsl:call-template>
</xsl:when>
<xsltherwise>
<xsl:value-of select="$w"/>
</xsltherwise>
</xsl:choose>
</xsl:template>

I also have this simple template for italic text:

<xsl:template match ="it">
<i><xsl:apply-templates/></i>
</xsl:template>

This works fine if I write something like:

<it><reg type="hyp" orig="Hyphe|nated">Hyphenated</reg></it>

Now I can choose if I want to preserve linebreaks or not.
But as it happens, in some of the texts I'm working on,
sometimes ony part of the word is in italics (or formatted
some other way), like <it>Hyphe</it>nated, and since I
can't do

<reg type="hyp" orig="<it>Hyphe</it>|nated"><it>Hyphe</it>nated</
reg>

I must write something like:

<choice type="hyp">
<orig><it>Hyphe</it>|nated</orig>
<reg><it>Hyphe</it>nated</reg>
</choice>

So for this I added the following templates:

<xsl:template match="choice[@type='hyp']">
<xsl:apply-templates select="./orig"/>
</xsl:template>

<xsl:template match="choice[@type='hyp']/orig">
<xsl:call-template name="html-hyphens"/>
</xsl:template>

But the combination of the <it> and <choose> elements
are not working. Can anyone help me out?

Thanks a lot
/Patrik Nyman

 

[Joseph Kesselman]

(Apologies for not trimming the quote.)

 

[patrik.nyman]

I'll try to look at this in more detail later, but... Y'know, this is
the sort of task that I would suggest handling in the redering engine,
rather than at the XML level. The renderer is the level which knows
where line breaks are going to have to be inserted, and is traditionally
where hyphenation is done as a result. That's generally driven by a
dictionary, though it could certainly take advantage of hints in the source.

I fully agree, but in this particular case, I'm doing markup of
pre-existing texts (from 18th century books) and need to
be able to make different versions, one that preserves the
original line breaks, and one where the rendering engine
(i.e., LaTeX) decides where to break lines. Hence
my markup, and my problem!

 

[=?ISO-8859-1?Q?J=FCrgen_Kahrs?=]

I fully agree, but in this particular case, I'm doing markup of
pre-existing texts (from 18th century books) and need to
be able to make different versions, one that preserves the
original line breaks, and one where the rendering engine
(i.e., LaTeX) decides where to break lines. Hence
my markup, and my problem!

Why dont you use one of the existing packages
for scholarly critical editions ?

http://www.ucl.ac.uk/~ucgadkw/edmac/index.html
http://ednotes.sty.de.vu/

 

[Joseph Kesselman]

http://ednotes.sty.de.vu/

Hm. ledmac is LaTeX-based, and I know folks have experiemented with XML
front-end syntaxes for LaTeX...

But I'm not going to dismiss this out of hand; sometimes inventing a new
markup is legitimate in order to get the behaviors you want. (After all
that's how edmac/ledmac started). So let's ignore the question of why
two alternate renderings are desired think about how we achieve them. My
instinct says stylesheet modes, but I want to look at the question again.

I'm a bit distracted right now; I'll try to get back to this later.

 

[Joseph Kesselman]

But the combination of the <it> and <choose> elements
are not working.

One obvious question: Do you have templates for <orig> and <reg>? Or at
least an explicit identity template which is catching these? If not,
you'll get XSLT's built-in default template, which just returns the
contained text -- and as a result you'll lose any markup below that
point, specifically the <it>.


("Not working" isn't a very useful description. It'd help if you could
post a minimal example of an input document, and a complete stylesheet
that contains just enough logic to demonstrate what you're doing and
what isn't working. Runnable examples are easier to review/debug than
out-of-context fragments, because they make obvious the answers to
questions like the one I just raised.)


Another obvious alternative would be to turn the markup inside out:
<it><reg type="hyp" orig="Hyphe|">Hyphe</reg></it>nated

Or to reconsider the whole thing and use something more like
<it>Hyphe<hyp/></it>nated
and then have <hyp/> either render as your visible hyphen or as nothing
depending on whether people want to see it.

(If your markup is making life complicated, maybe it's the wrong markup...)

 

[patrik.nyman]

("Not working" isn't a very useful description. It'd help if you could
post a minimal example of an input document, and a complete stylesheet
that contains just enough logic to demonstrate what you're doing and
what isn't working.

Of course, se bottom of this post

Another obvious alternative would be to turn the markup inside out:
<it><reg type="hyp" orig="Hyphe|">Hyphe</reg></it>nated

Or to reconsider the whole thing and use something more like
<it>Hyphe<hyp/></it>nated
and then have <hyp/> either render as your visible hyphen or as nothing
depending on whether people want to see it.

Originally, I wanted the <reg type="hyp" orig="Hyphe|
nated">Hyphenated</reg>
markup so the hyphenated word would be avaliable for greping and
database
searches, etc. But now I realize if I'm gonna stick <it>'s in there
it
can't be greped anyway... So maybe I need something like

<choice type="hyp">
<orig><it>Hyphe</it>|nated</orig>
<reg><it>Hyphe</it>nated</reg>
<plain>Hyphenated</plain>
</choice>

And then it starts getting out of hand...

Anyway, it would be interesting if my example could be made to work.
It would be useful in other situations as well. So here's the example.
Nr 1 and 4 works as expected, nr 2 gives no italics, nr 3 gives no
output at all.

%<--------------------------------------------------------------------

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="application/xml" href="./hyp.xsl"?>

<!DOCTYPE TEST>

<TEST>

<it><reg type="hyp" orig="Hyphe|nated-1">Hyphenated-1</reg></it>

<choice type="hyp">
<orig><it>Hyphe</it>|nated-2</orig>
<reg><it>Hyphe</it>nated-2</reg>
</choice>

<choice type="hyp">
<it><orig>Hyphe|nated-3</orig></it>
<it><reg>Hyphenated-3</reg></it>
</choice>

<it>
<choice type="hyp">
<orig>Hyphe|nated-4</orig>
<reg>Hyphenated-4</reg>
</choice>
</it>

</TEST>

%<--------------------------------------------------------------------

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xd="http://www.pnp-software.com/XSLTdoc">

<xslutput method="html"/>

<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>

<xsl:template match ="it">
<i><xsl:apply-templates/></i>
</xsl:template>

<xsl:template match="reg[@type='hyp']">
<xsl:apply-templates select="@orig"/>
</xsl:template>

<xsl:template match="reg[@type='hyp']/@orig">
<xsl:call-template name="html-hyphens"/>
</xsl:template>

<xsl:template match="orig">
<xsl:apply-templates/>
</xsl:template>

<xsl:template match="reg">
<xsl:apply-templates/>
</xsl:template>

<xsl:template match="choice[@type='hyp']">
<xsl:apply-templates select="./orig"/>
</xsl:template>

<xsl:template match="choice[@type='hyp']/orig">
<xsl:call-template name="html-hyphens"/>
</xsl:template>

<xsl:template name="html-hyphens">
<xslaram name="w" select="."/>
<xsl:variable name="car"
select="substring-before($w,'|')"/>
<xsl:variable name="cdr"
select="substring-after($w,'|')"/>
<xsl:choose>
<xsl:when test="$cdr">
<xsl:value-of select="concat($car,'-')"/>
<br/>
<xsl:call-template name="html-hyphens">
<xsl:with-param name="w" select="$cdr"/>
</xsl:call-template>
</xsl:when>
<xsltherwise>
<xsl:value-of select="$w"/>
</xsltherwise>
</xsl:choose>
</xsl:template>

</xsl:stylesheet>

%<-------------------------------------------------------------

/Patrik Nyman

 

[Joe Kesselman]

nr 2 gives no italics, nr 3 gives no output at all.

OK, let's look at it.

#2:
"choice[@type='hyp']" applies templates against its <orig> child.
That's matched by the template for "choice[@type='hyp']/orig".
This hands off to named template "html-hyphens" with no parameter.
The parameter's default value is ., which will be the <orig> element.
All that's done with the parameter is to take its string value.
String value of that <orig> is the concatenation of its text
descendants; the <it> is correctly ignored.


#3 is even more obvious: You're explicitly processing the <orig> child.
There is no <orig> child; the child elements are both <it> elements.


You're getting exactly what you asked for. If it isn't what you wanted,
slow down and think about exactly what you're trying to recognize at
each stage and what you want to do with it. XSLT is a programming
language; it does only and exactly what you tell it to do.

Coming up with a version which handles all four cases is left as an
exercise for the student. Hint: If you want to recognize the two options
and select between them no matter how deeply buried they are in other
markup, you're going to have to select which subtree to process based
upon its descendants.

Personally, I still think you're needlessly complicating the problem.
Were I in your shoes I'd be fighting to get the markup designed from
first principles in a form that's actually amenable to straightforward
processing rather than trying to tolerate sloppy usage. You should be
able to achieve that while still retaining all the historical
information, if you take the time to structure your descriptive
hierarchies correctly.

 

[patrik.nyman]

OK, let's look at it.

Thanks for your input. I think your hints will help me solve
the problem.

/Patrik