Re: Pattern matching error in xsl:key

On Sat, Sep 5, 2020 at 11:56 AM Martin Honnen <[email protected]> wrote:

> Am 05.09.2020 um 17:34 schrieb Ihe Onwuka:
>
> > No doubt in excerpting I omitted some relevant info. I'll try and fix
> > that. The XML content is in a separate document and globally namespaced.
> > Here.
> >
> > <versionChanges xmlns="http://changes" >
> >    <changes from="4.0" to="4.1">
> >       <rename>
> >          <metadata/>
> >       </rename>
> >    </changes>
> > </versionChanges>
> >
> > and here is the error message
> >
> > Warning at char 11 in xsl:key/@match on line 36 column 111 of
> > myStylesheet.xsl:
> >    XPTY0004  An error occurred matching pattern
> >
> > {element(Q{http://changes}changes)[((data(attribute::attribute(Q{}from)))
> eq
> >    (atomizeSingleton($source))) and ((data(attribute::attribute(Q{}to)))
> eq
> >    (atomizeSingleton($target)))]}:
> >
> >     My guess would be that it's a type error connected with the fact
> >     you're comparing numbers to strings, but beyond that,
> >
> >
> > I am comparing parameters whose values are 4.0 and 4.1 respectively to
> > attributes whose values are 4.0 and 4.1 respectively. Saxon has made
> > it's own assumptions about what types they are and come up with that
> error.
>
> The types are not made up by Saxon but are defined in the XPath/XSLT
> specs. In the XSLT code if you declare
>
>    <xsl:param name="source" select="4.0"/>
>
> the expression 4.0 in the select attribute is of type xs:decimal (in a
> version="2.0" or version="3.0" XSLT code).
>
> However, in your untyped XML the attribute value of e.g. @from or @to is
> of type xs:untypedAtomic.
>
>
Illuminating.
So if we come up from the weeds of the spec you've basically got a
situation where the spec is assigning different types to the same identical
value because they are placed in different constructs.
So while being correct it's not a very good explanation to have to give.

Note that AFAIA aware at least I cannot supply type information for
the @from and @to attributes in the context in which they are being used.




> The eq operator only works if both operands have a comparable type, in
> your case the rules in
> https://www.w3.org/TR/xpath-31/#id-value-comparisons (5.d) give
> "Otherwise, a type error is raised [err:XPTY0004].".
>
>
They are the same untyped value - therefore the types should be comparable
- the spec has interpreted that situation wr... wro... differently :)


> So using = instead of eq is one way to avoid that, as it in 4.a of
> https://www.w3.org/TR/xpath-31/#id-general-comparisons stipulates: "If
> at least one of the two atomic values is an instance of a numeric type,
> then both atomic values are converted to the type xs:double by applying
> the fn:number function".
>

Well you know why I didn't use =, I didn't need existential evaluation.
Interesting. Cheers.

>
>
>
>
>
>
>
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[email protected]
https://lists.sourceforge.net/lists/listinfo/saxon-help