Re: [xsl] Puzzling ambiguous match

Subject: Re: [xsl] Puzzling ambiguous match
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 19 Jan 2011 17:26:37 +0000
Interesting. I removed all the match options in the long null template
except the one for p[normalize-space(.)=''] (I also removed the
predicate about graphics).

Now it says:

so it really does seem to be interpreting the paragraph as having no
string content.
Either that, or it's matching a different paragraph from the one you claim it's matching. Further tests needed...

That's fine. There were other issues :-) Like //foo//title[1] returning all title descendants of foo which are in position()=1 with respect to their parent element. Which I think is correct, but misleading: a user would expect it to return the first occurrence only of title anywhere within foo, when what they should be using is (//foo//title)[1] :-)

I doubt very much that Xalan is handling //foo//title[1] as (//foo//title)[1], which would be a gross non-conformance whatever users expect: much more likely, this is an XSLT 1.0/2.0 difference where the expression //foo//title[1] appears in a context (such as xsl:value-of) where all nodes except the first are ignored.


Michael Kay
Saxonica


///Peter

On 19/01/2011 11:05, Peter Flynn wrote:
This has me baffled. I'm either being incredibly dense, or there's
something going on here I have failed to grok.

I upgraded my Cocoon to Saxon 9, and it's revealing holes in some
ancient XSLT 1.0 (which is good). They're all due for a rewrite, but I
need to fix them first because they're not serving. This particular
application serves Word XML (shorn of its namespaces) as HTML.

The one that came up this morning looks odd:

net.sf.saxon.trans.XPathException: Ambiguous rule match for
/package/part[3]/xmlData[1]/document[1]/body[1]/tbl[1]/tr[1]/tc[2]/p[1]
That's OK, this is a para in the second column of the first row of a
table in a Word document. It looks like this:

<p rsidR="001E130F" rsidRPr="00527737" rsidRDefault="00527737" rsidP="00527737">
   <pPr>
     <pStyle val="ListBullet"/>
     <numPr>
       <ilvl val="0"/>
       <numId val="0"/>
     </numPr>
   </pPr>
   <r rsidRPr="00527737">
     <t>Jemandem das Recht geben, etwas zu tun</t>
   </r>
</p>
Yep, it's a para, and the author wants it bulleted. In a table cell, but
that's the editor's business. Nothing wrong so far.

Matches both "p[pPr[pStyle[@val='ListNumber']]] | p[pPr[pStyle[@val='ListBullet']]]"
on line 668 of file:///var/www/xml/journals/scenario/xsl/scenario2html-raw.xsl
I'll buy that, it is indeed a list bullet item, and the template on line
668 will indeed make it so. And the para is indeed being invoked
correctly via apply-templates from within the template matching its
parent "tc" elsewhere in the XSLT.

But then we have:

and "p[normalize-space(.)='']
       [not(descendant::binData or descendant::imagedata or descendant::graphic)] |
p[pPr[pStyle[@val='ScenarioLogoHeading1']]] |
p[pPr[pStyle[@val='ScenarioTitle1TitelaufDeckblatt']]] |
p[pPr[pStyle[@val='ScenarioAuthor1DeckblattAutorenname']]] |
p[pPr[pStyle[@val='ScenarioISSNNumberNummer']]] |
p[pPr[pStyle[@val='Header']]] |
p[pPr[pStyle[@val='Footer']]] |
p[pPr[pStyle[@val='CommentText']]] |
p[pPr[pStyle[@val='StyleScenarioLogoHeading1Bold']]] |
p[pPr[pStyle[@val='ScenarioTitle2TitelTextanfang']]] |
hdr[pBdrGroup[p[pPr[rPr[rStyle[@val='PageNumber']]]]]] |
p[pPr[pStyle[@val='ScenarioAuthor2AutorennameTextanfang']]]|
p[pPr[pStyle[@val='SCBlockcitationBlockzitat']]]
  [preceding-sibling::*[1][name()='p'][pPr[pStyle[@val='Title']]]]"
on line 180 of
file:///var/www/xml/journals/scenario/xsl/scenario2html-raw.xsl

This is a null template suppressing empty paragraphs provided they are
not part of an illustration (where they may validly be empty but we need
their attributes); it also suppresses all the horrible gunk that
previous editors' style templates have left hanging around, and that we
just don't want.

But my para from the table isn't empty, and its styling doesn't match
any of the ones in this second template. I'm not clear what it is that
Saxon has found to make it match ambiguously.

Before I start chopping away one by one, is there something I have
missed about Saxon's behaviour compared to Xalan (the previous engine in
this server, which allowed all kinds of things to go on :-)

///Peter

Current Thread