From gfourny at inf.ethz.ch  Tue Nov 10 02:33:46 2020
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Tue, 10 Nov 2020 10:33:46 +0000
Subject: [xquery-talk] Castable as with maps/arrays
Message-ID: <A2E33722-FA4C-4966-9D74-FF83FDBC65D1@inf.ethz.ch>

Dear all,

I would like to check something on XQuery 3.1 and in particular the behavior of maps/arrays with "castable as" given the way they can and cannot be atomized.

Do you agree that

  array { 1, 2 } castable as xs:integer

and

  map {} castable as xs:integer

should both return false?


My first thought was to see what Saxon (I used 9.9.1.7) says (in oXygen) but the first query returns true in spite of

  array { 1, 2 } cast as xs:integer

throwing an error (as expected)

and the second query returns a null pointer exception (in all likelihood, this one is undesired).

Thanks a lot for confirming whether my understanding of the spec is correct!

Thanks and kind regards,
Ghislain



From gfourny at inf.ethz.ch  Tue Nov 10 08:22:13 2020
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Tue, 10 Nov 2020 16:22:13 +0000
Subject: [xquery-talk] Castable as with maps/arrays
In-Reply-To: <E1AD95B0-CD92-4C21-8F0E-E1D329090DBC@saxonica.com>
References: <A2E33722-FA4C-4966-9D74-FF83FDBC65D1@inf.ethz.ch>
	<E1AD95B0-CD92-4C21-8F0E-E1D329090DBC@saxonica.com>
Message-ID: <D4C4F333-1429-4C15-8AD2-C19348DF5DEB@inf.ethz.ch>

Dear Mike,

Thanks a lot for your response and for extending the test suite accordingly.

I indeed missed "or if the value of E cannot be atomized" at first read, meaning that indeed map{} castable as anything should fail with an error.

Kind regards and have a nice evening,
Ghislain


> On 10 Nov 2020, at 11:54, Michael Kay <mike at saxonica.com> wrote:
> 
> The spec says (very carefully)
> 
> The expression E castable as T returns true if the result of evaluating E can be successfully cast into the target type T by using a cast expression; otherwise it returns false. If evaluation of E fails with a dynamic error or if the value of E cannot be atomized, the castable expression as a whole fails.
> 
> So if E is map{} then there should definitely be an error because map{} cannot be atomized. (It's less clear exactly what the error should be, or whether it can be reported statically).
> 
> If E is array{1,2} then I think the spec says the result should be false: evaluation of E does not fail, and it can be atomized, and it cannot be cast to xs:integer.
> 
> I will add some test cases to QT3.
> 
> Michael Kay
> Saxonica
> 
>> On 10 Nov 2020, at 10:33, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
>> 
>> Dear all,
>> 
>> I would like to check something on XQuery 3.1 and in particular the behavior of maps/arrays with "castable as" given the way they can and cannot be atomized.
>> 
>> Do you agree that
>> 
>>  array { 1, 2 } castable as xs:integer
>> 
>> and
>> 
>>  map {} castable as xs:integer
>> 
>> should both return false?
>> 
>> 
>> My first thought was to see what Saxon (I used 9.9.1.7) says (in oXygen) but the first query returns true in spite of
>> 
>>  array { 1, 2 } cast as xs:integer
>> 
>> throwing an error (as expected)
>> 
>> and the second query returns a null pointer exception (in all likelihood, this one is undesired).
>> 
>> Thanks a lot for confirming whether my understanding of the spec is correct!
>> 
>> Thanks and kind regards,
>> Ghislain
>> 
>> 
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
> 



From mike at saxonica.com  Wed Nov 11 00:25:07 2020
From: mike at saxonica.com (Michael Kay)
Date: Wed, 11 Nov 2020 08:25:07 +0000
Subject: [xquery-talk] Default element namespace: multiple declarations
Message-ID: <A6961C80-549A-488F-987D-9FB608364A6A@saxonica.com>

I can't see any rule that makes it an error to write

import schema default element namespace "http://example.org/abc";
declare default element namespace "http://example.org/xyz";

This looks to me like an oversight in the spec.

I think Saxon simply uses whichever one comes last.

Any thoughts?

Michael Kay
Saxonica

From gfourny at inf.ethz.ch  Wed Nov 11 02:49:29 2020
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Wed, 11 Nov 2020 10:49:29 +0000
Subject: [xquery-talk] Default element namespace: multiple declarations
In-Reply-To: <A6961C80-549A-488F-987D-9FB608364A6A@saxonica.com>
References: <A6961C80-549A-488F-987D-9FB608364A6A@saxonica.com>
Message-ID: <55118F91-AD70-4489-89BE-C3F6BFD379A2@inf.ethz.ch>

Dear Mike,

That's a good catch.

If we want to "save the spirit of the spec" while stretching its letter reasonably, my interpretation of

  "The schema import may [...] declare that target namespace to be the default element/type namespace"

is that a schema import that declares a default element/type namespace also literally constitutes a "default element/type namespace declaration" in an extended sense (in addition to the "vanilla" default element/type namespace declarations of 4.14).

As a consequence, my interpretation of

"A Prolog may contain at most one default element/type namespace declaration [err:XQST0066]."

would speak in favor of throwing XQST0066 for the query below.

Does this reasoning make sense?

Kind regards,
Ghislain

> On 11 Nov 2020, at 09:25, Michael Kay <mike at saxonica.com> wrote:
> 
> I can't see any rule that makes it an error to write
> 
> import schema default element namespace "http://example.org/abc";
> declare default element namespace "http://example.org/xyz";
> 
> This looks to me like an oversight in the spec.
> 
> I think Saxon simply uses whichever one comes last.
> 
> Any thoughts?
> 
> Michael Kay
> Saxonica
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From ihe.onwuka at gmail.com  Sun Nov 15 04:32:20 2020
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Sun, 15 Nov 2020 07:32:20 -0500
Subject: [xquery-talk] Results with distinct-values varies dependent on
	syntax
Message-ID: <CALfs7+x4eEeiSqOr-99X3n48kU4JuwZhh74my2n-12Pa_myJ-Q@mail.gmail.com>

xquery version "3.1";

let $schemaCollection := "/db/apps/schemas"
 return
collection($schemaCollection)/xs:schema/distinct-values(@targetNamespace)

does not eliminate duplicates

xquery version "3.1";

let $schemaCollection := "/db/apps/schemas"
 return collection($schemaCollection)/xs:schema/@targetNamespace =>
distinct-values()

does.

I checked this in Saxon and exist-db XQuery, both return the same results
so this may be how it's supposed to work but I don't get it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20201115/363baeb5/attachment.html>

From davidc at nag.co.uk  Sun Nov 15 05:03:15 2020
From: davidc at nag.co.uk (David Carlisle)
Date: Sun, 15 Nov 2020 13:03:15 +0000
Subject: [xquery-talk] Results with distinct-values varies dependent on
 syntax
In-Reply-To: <CALfs7+x4eEeiSqOr-99X3n48kU4JuwZhh74my2n-12Pa_myJ-Q@mail.gmail.com>
References: <CALfs7+x4eEeiSqOr-99X3n48kU4JuwZhh74my2n-12Pa_myJ-Q@mail.gmail.com>
Message-ID: <02897b36-c889-b458-f7b3-99a1295db6dd@nag.co.uk>

On 15/11/2020 12:32, Ihe Onwuka wrote:
> xquery version "3.1";
>
> let $schemaCollection := "/db/apps/schemas"
> ?return 
> collection($schemaCollection)/xs:schema/distinct-values(@targetNamespace)
>
> does not eliminate duplicates
>
> xquery version "3.1";
>
> let $schemaCollection := "/db/apps/schemas"
> ?return collection($schemaCollection)/xs:schema/@targetNamespace => 
> distinct-values()
>
> does.
>
> I checked this in Saxon and exist-db XQuery, both return the same 
> results so this may be how it's supposed to work but I don't get it.
>
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

distinct-values(@targetNamespace)


returns the input sequence with duplicates (by value) removed but 
@targetNamespace only selects at most one attribute so distinct-values 
will do nothing.

$schemaCollection)/xs:schema/@targetNamespace => distinct-values()

or

distinct-values($schemaCollection)/xs:schema/@targetNamespace)


here you first make the sequence of all the @targetNamespace then remove 
duplicates.


David

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20201115/9789811b/attachment.html>

From ihe.onwuka at gmail.com  Mon Nov 16 03:16:52 2020
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 16 Nov 2020 06:16:52 -0500
Subject: [xquery-talk] Deep equally distinct-values
Message-ID: <CALfs7+yRvPBqGAqVnAUgBvHjrfVyTKXhwwGBcYbYCe9FwaBQZw@mail.gmail.com>

Is there a distinct-value equivalent for non-atomic types or would one have
to roll ones own.
Am ok doing that just want to make sure I need to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20201116/5d06d598/attachment.html>

From gfourny at inf.ethz.ch  Mon Nov 16 03:25:59 2020
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Mon, 16 Nov 2020 11:25:59 +0000
Subject: [xquery-talk] Deep equally distinct-values
In-Reply-To: <CALfs7+yRvPBqGAqVnAUgBvHjrfVyTKXhwwGBcYbYCe9FwaBQZw@mail.gmail.com>
References: <CALfs7+yRvPBqGAqVnAUgBvHjrfVyTKXhwwGBcYbYCe9FwaBQZw@mail.gmail.com>
Message-ID: <C95D11BB-7877-4F3D-9538-C82088D8AA96@inf.ethz.ch>

Dear Ihe,

The closest I can think of (which is not in the standard library) is

http://www.xqueryfunctions.com/xq/functx_distinct-deep.html
http://www.xqueryfunctions.com/xq/functx_distinct-nodes.html

Kind regards,
Ghislain


> On 16 Nov 2020, at 12:16, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
> 
> Is there a distinct-value equivalent for non-atomic types or would one have to roll ones own. 
> Am ok doing that just want to make sure I need to.
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From ihe.onwuka at gmail.com  Mon Nov 16 08:07:29 2020
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 16 Nov 2020 11:07:29 -0500
Subject: [xquery-talk] Issues with recursive fn:transform
Message-ID: <CALfs7+yWB5n1OpVqoYOXRF9-3bD4b3rfd3WRXf7Zdz_ptnDUEw@mail.gmail.com>

Below is a recursive fn:transform function.
Takes 2 arguments - the XML and the accumulator and recursively calls a
translator.xsl to generate a translation of the XML into the next version.
That's what is supposed to happen, it infinitely loops because the next
version of the XML is being generated so the base case is never true -
can't see a reason why that should happen but for now I will settle for
hopefully understanding something more straightforward

   <xsl:function name="local:x" as="element()+">
      <xsl:param name="currentVersion" as="element()"/>
      <xsl:param name="accum" as="element()+"/>
      <xsl:sequence select="if (namespace-uri($currentVersion/*) =>
contains($finalTarget))
                            then ($currentVersion,$accum)
                            else local:x(fn:transform(map {
                                                       'stylesheet-node' :
 doc(''),
                                      'source-node'     :  $currentVersion
                                              })?output/*,
                        $accum)"/>
   </xsl:function>

I have used the old doc('') trick to pass the current stylesheet (the name
is translator.xsl) to the recursive call but that is not the value supplied
as the first argument of local:x but the error message says it is

XPTY0004  The required item type of the first argument of local:x() is
element(); the
  supplied value doc(.../translator.xsl) does not match. The supplied value
is a document node
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20201116/b288040a/attachment.html>

From ihe.onwuka at gmail.com  Mon Nov 16 11:59:37 2020
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 16 Nov 2020 14:59:37 -0500
Subject: [xquery-talk] Issues with recursive fn:transform
In-Reply-To: <CALfs7+yWB5n1OpVqoYOXRF9-3bD4b3rfd3WRXf7Zdz_ptnDUEw@mail.gmail.com>
References: <CALfs7+yWB5n1OpVqoYOXRF9-3bD4b3rfd3WRXf7Zdz_ptnDUEw@mail.gmail.com>
Message-ID: <CALfs7+xracRkXq9pJ5-jd1=WMoLffbv7w=Res=tVsVELsQWD=g@mail.gmail.com>

I have got the recursive function to work by simplifying the call to
eliminate the accumulator.
I think the error message is an issue. I shouldn't have got that.


On Mon, Nov 16, 2020 at 11:07 AM Ihe Onwuka <ihe.onwuka at gmail.com> wrote:

> Below is a recursive fn:transform function.
> Takes 2 arguments - the XML and the accumulator and recursively calls a
> translator.xsl to generate a translation of the XML into the next version.
> That's what is supposed to happen, it infinitely loops because the next
> version of the XML is being generated so the base case is never true -
> can't see a reason why that should happen but for now I will settle for
> hopefully understanding something more straightforward
>
>    <xsl:function name="local:x" as="element()+">
>       <xsl:param name="currentVersion" as="element()"/>
>       <xsl:param name="accum" as="element()+"/>
>       <xsl:sequence select="if (namespace-uri($currentVersion/*) =>
> contains($finalTarget))
>                             then ($currentVersion,$accum)
>                             else local:x(fn:transform(map {
>                                                        'stylesheet-node' :
>  doc(''),
>                                       'source-node'     :  $currentVersion
>                                               })?output/*,
>                         $accum)"/>
>    </xsl:function>
>
> I have used the old doc('') trick to pass the current stylesheet (the name
> is translator.xsl) to the recursive call but that is not the value supplied
> as the first argument of local:x but the error message says it is
>
> XPTY0004  The required item type of the first argument of local:x() is
> element(); the
>   supplied value doc(.../translator.xsl) does not match. The supplied
> value is a document node
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20201116/8cfe817f/attachment.html>

From ihe.onwuka at gmail.com  Thu Nov 19 03:55:44 2020
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 19 Nov 2020 06:55:44 -0500
Subject: [xquery-talk] What should document-uri return for an invocation of
	fn:transform
Message-ID: <CALfs7+wnf+2W1S6ZTqFbgu4dn1_3hQryXfAVRsu1+aPUVCP46w@mail.gmail.com>

..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20201119/b255fb36/attachment.html>