[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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[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
|
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
|