Re: Puzzling ambiguous match

If XPath 1.0 compatibility mode is on, the node (<p>) is to be
converted to xs:string. According to the documents, this results in
the string-value of <p> and this " must be the concatenation of the
string-values of all its Text Node descendants". But <p> has no text
nodes in it.

What is it I fail to see/understand?
-W

On 19 January 2011 12:26, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>
> I certainly can't see from staring at it how that <p> element matches that
rule. I would attempt diagnosis by splitting up the rule into simpler
sub-rules and seeing what happens.
>
> As regards Saxon vs Xalan, I believe Xalan doesn't attempt to detect
ambiguous rule matches, it just chooses the one that comes last, as the spec
allows it to.
>
> Michael Kay
> Saxonica
>
> 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