[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Puzzling ambiguous match

Subject: Re: Puzzling ambiguous match
From: Peter Flynn <pflynn@xxxxxx>
Date: Wed, 19 Jan 2011 16:59:54 +0000
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.

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


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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.