Re: Puzzling ambiguous match

On 19/01/11 12:06, Wolfgang Laun wrote:
> 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.

Yes, the paragraph as given contains the text node descendant "Jemandem
das Recht geben, etwas zu tun".

The whitespace is not present in the original, where the document stores
it as <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>
I just added it so you could read it more easily.

> What is it I fail to see/understand?

I'm not sure.

///Peter

> 
> 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