On 19 January 2011 12:26, Michael Kay <mike(_at_)saxonica(_dot_)com> 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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or
e-mail:<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--