Subject: Re: [xsl] Puzzling ambiguous match From: Wolfgang Laun <wolfgang.laun@xxxxxxxxx> Date: Wed, 19 Jan 2011 13:06:52 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Puzzling ambiguous match, Michael Kay | Thread | Re: [xsl] Puzzling ambiguous match, Michael Kay |
Re: [xsl] Puzzling ambiguous match, Michael Kay | Date | Re: [xsl] Puzzling ambiguous match, Michael Kay |
Month |