Re: [xsl] Puzzling ambiguous match

[Peter Flynn <pflynn@xxxxxx>]

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.

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:

>> 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]
>> Matches both "p[pPr[pStyle[@val='ListNumber']]] | 
>> p[pPr[pStyle[@val='ListBullet']]]" on line 652 ...
>> and "p[normalize-space(.)='']" on line 164 

so it really does seem to be interpreting the paragraph as having no
string content.

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.

Something, somewhere, is failing to reduce the paragraph to the correct
string value.

[Mike]
> 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.

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] :-)

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