Re: Puzzling ambiguous match
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/xmlData/document/body/tbl/tr/tc/p >> 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 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) :-) ///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/xmlData/document/body/tbl/tr/tc/p >>> >>> 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::*[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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format