From wshager at gmail.com  Tue Aug  1 05:27:44 2017
From: wshager at gmail.com (W.S. Hager)
Date: Tue, 1 Aug 2017 14:27:44 +0200
Subject: [xquery-talk] arrow operator
Message-ID: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>

Hi,

Is there any advantage to using the 3.1 arrow operator over the simple map
operator?

$string => upper-case() => normalize-unicode() => tokenize("\s+")

versus

$string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")

Thanks,
Wouter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170801/e41a644a/attachment.html>

From christian.gruen at gmail.com  Tue Aug  1 05:41:17 2017
From: christian.gruen at gmail.com (=?UTF-8?Q?Christian_Gr=C3=BCn?=)
Date: Tue, 1 Aug 2017 14:41:17 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
Message-ID: <CAP94bnMkqVub8d7brjd3wrTbqiFUwGuxbfs37dD8XuOqGiZQ7g@mail.gmail.com>

Hi Wouter,

The arrow operator takes all items of the left side as first argument,
whereas the simple map operator processes all items one by one:

  (1,2,3) => count()   ? 3
  (1,2,3) ! count(.)   ? 1 1 1

Cheers,
Christian


On Tue, Aug 1, 2017 at 2:27 PM, W.S. Hager <wshager at gmail.com> wrote:
> Hi,
>
> Is there any advantage to using the 3.1 arrow operator over the simple map
> operator?
>
> $string => upper-case() => normalize-unicode() => tokenize("\s+")
>
> versus
>
> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
>
> Thanks,
> Wouter
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From mike at saxonica.com  Tue Aug  1 09:58:25 2017
From: mike at saxonica.com (Michael Kay)
Date: Tue, 1 Aug 2017 17:58:25 +0100
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
Message-ID: <C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>

In the case of singletons there's very little difference, but (as I now see Christian has pointed out), with sequences the effect is quite different.

Also, of course, "!" changes the context item, so

@address => replace(@postcode, "", "q") works, while

@address ! replace(@postcode, "", "q") doesn't.

Michael Kay
Saxonica

> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
> 
> Hi,
> 
> Is there any advantage to using the 3.1 arrow operator over the simple map operator?
> 
> $string => upper-case() => normalize-unicode() => tokenize("\s+")
> 
> versus
> 
> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> 
> Thanks,
> Wouter
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From wshager at gmail.com  Wed Aug  2 02:27:06 2017
From: wshager at gmail.com (W.S. Hager)
Date: Wed, 2 Aug 2017 11:27:06 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
Message-ID: <CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>

Hi Michael,

The way you used the arrow operator in the example would be the way I
expected it to work, namely by explicitly addressing the context, but it
seems that it doesn't. It's actually implicitly binding the first argument
of the function on the right to the value on the left. Or is there an
exception I don't know about?

Thanks.

Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:

In the case of singletons there's very little difference, but (as I now see
Christian has pointed out), with sequences the effect is quite different.

Also, of course, "!" changes the context item, so

@address => replace(@postcode, "", "q") works, while

@address ! replace(@postcode, "", "q") doesn't.

Michael Kay
Saxonica

> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
>
> Hi,
>
> Is there any advantage to using the 3.1 arrow operator over the simple
map operator?
>
> $string => upper-case() => normalize-unicode() => tokenize("\s+")
>
> versus
>
> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
>
> Thanks,
> Wouter
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170802/3ae3c920/attachment.html>

From gfourny at inf.ethz.ch  Wed Aug  2 03:00:23 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Wed, 2 Aug 2017 10:00:23 +0000
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
Message-ID: <DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>

Dear Wouter,

There is one more important difference on the syntactic level.

With the arrow operator, the left-hand-side is implicitly bound to the first parameter of the function.

@address => replace(@postcode, "", "q")

is the same as

replace(@address, @postcode, "", "q")


With the simple map operator, the context item must be explicitly referred to, like so:

@address ! replace(., @postcode, "", "q")


What may create confusion is that some functions have several signatures, some of which implicitly refer to the context item. But this is a very different mechanism.

For example :

@address ! string(.) (: explicitly passed context item :)
@address ! string() (: context item passed implicitly to string#0, which is context-dependent)
@address => string() (: context item passed implicitly to string#1 via the => operator, but string#1 is context-independent)

I hope I got it right!

Kind regards,
Ghislain


> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
> 
> Hi Michael,
> 
> The way you used the arrow operator in the example would be the way I expected it to work, namely by explicitly addressing the context, but it seems that it doesn't. It's actually implicitly binding the first argument of the function on the right to the value on the left. Or is there an exception I don't know about?
> 
> Thanks.
> 
> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
> In the case of singletons there's very little difference, but (as I now see Christian has pointed out), with sequences the effect is quite different.
> 
> Also, of course, "!" changes the context item, so
> 
> @address => replace(@postcode, "", "q") works, while
> 
> @address ! replace(@postcode, "", "q") doesn't.
> 
> Michael Kay
> Saxonica
> 
> > On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
> >
> > Hi,
> >
> > Is there any advantage to using the 3.1 arrow operator over the simple map operator?
> >
> > $string => upper-case() => normalize-unicode() => tokenize("\s+")
> >
> > versus
> >
> > $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> >
> > Thanks,
> > Wouter
> > _______________________________________________
> > talk at x-query.com
> > http://x-query.com/mailman/listinfo/talk
> 
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From gfourny at inf.ethz.ch  Wed Aug  2 03:04:12 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Wed, 2 Aug 2017 10:04:12 +0000
Subject: [xquery-talk] arrow operator
In-Reply-To: <DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
Message-ID: <D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>

... I didn't get it quite right actually. In @address => string(), there is no context item involved, I wrote too fast. :-)

New attempt:

@address ! string(.) (: explicitly passed context item :)
@address ! string() (: context item passed implicitly to string#0, which is context-dependent)
@address => string() (: @address passed implicitly to string#1 as the first parameter via the => operator, but string#1 is context-independent)
@address => string(.) (: error: string#2 does not exist :)

Kind regards,
Ghislain


> On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
> 
> Dear Wouter,
> 
> There is one more important difference on the syntactic level.
> 
> With the arrow operator, the left-hand-side is implicitly bound to the first parameter of the function.
> 
> @address => replace(@postcode, "", "q")
> 
> is the same as
> 
> replace(@address, @postcode, "", "q")
> 
> 
> With the simple map operator, the context item must be explicitly referred to, like so:
> 
> @address ! replace(., @postcode, "", "q")
> 
> 
> What may create confusion is that some functions have several signatures, some of which implicitly refer to the context item. But this is a very different mechanism.
> 
> For example :
> 
> @address ! string(.) (: explicitly passed context item :)
> @address ! string() (: context item passed implicitly to string#0, which is context-dependent)
> @address => string() (: context item passed implicitly to string#1 via the => operator, but string#1 is context-independent)
> 
> I hope I got it right!
> 
> Kind regards,
> Ghislain
> 
> 
>> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
>> 
>> Hi Michael,
>> 
>> The way you used the arrow operator in the example would be the way I expected it to work, namely by explicitly addressing the context, but it seems that it doesn't. It's actually implicitly binding the first argument of the function on the right to the value on the left. Or is there an exception I don't know about?
>> 
>> Thanks.
>> 
>> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
>> In the case of singletons there's very little difference, but (as I now see Christian has pointed out), with sequences the effect is quite different.
>> 
>> Also, of course, "!" changes the context item, so
>> 
>> @address => replace(@postcode, "", "q") works, while
>> 
>> @address ! replace(@postcode, "", "q") doesn't.
>> 
>> Michael Kay
>> Saxonica
>> 
>>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Is there any advantage to using the 3.1 arrow operator over the simple map operator?
>>> 
>>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
>>> 
>>> versus
>>> 
>>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
>>> 
>>> Thanks,
>>> Wouter
>>> _______________________________________________
>>> talk at x-query.com
>>> http://x-query.com/mailman/listinfo/talk
>> 
>> 
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
> 



From wshager at gmail.com  Wed Aug  2 03:07:14 2017
From: wshager at gmail.com (W.S. Hager)
Date: Wed, 2 Aug 2017 12:07:14 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
Message-ID: <CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>

Hi Ghislain,

Alright, I forgot about fn:replace#4, but the implicit binding is sometimes
hard to detect.

Thanks.

2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:

> ... I didn't get it quite right actually. In @address => string(), there
> is no context item involved, I wrote too fast. :-)
>
> New attempt:
>
> @address ! string(.) (: explicitly passed context item :)
> @address ! string() (: context item passed implicitly to string#0, which
> is context-dependent)
> @address => string() (: @address passed implicitly to string#1 as the
> first parameter via the => operator, but string#1 is context-independent)
> @address => string(.) (: error: string#2 does not exist :)
>
> Kind regards,
> Ghislain
>
>
> > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
> >
> > Dear Wouter,
> >
> > There is one more important difference on the syntactic level.
> >
> > With the arrow operator, the left-hand-side is implicitly bound to the
> first parameter of the function.
> >
> > @address => replace(@postcode, "", "q")
> >
> > is the same as
> >
> > replace(@address, @postcode, "", "q")
> >
> >
> > With the simple map operator, the context item must be explicitly
> referred to, like so:
> >
> > @address ! replace(., @postcode, "", "q")
> >
> >
> > What may create confusion is that some functions have several
> signatures, some of which implicitly refer to the context item. But this is
> a very different mechanism.
> >
> > For example :
> >
> > @address ! string(.) (: explicitly passed context item :)
> > @address ! string() (: context item passed implicitly to string#0, which
> is context-dependent)
> > @address => string() (: context item passed implicitly to string#1 via
> the => operator, but string#1 is context-independent)
> >
> > I hope I got it right!
> >
> > Kind regards,
> > Ghislain
> >
> >
> >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
> >>
> >> Hi Michael,
> >>
> >> The way you used the arrow operator in the example would be the way I
> expected it to work, namely by explicitly addressing the context, but it
> seems that it doesn't. It's actually implicitly binding the first argument
> of the function on the right to the value on the left. Or is there an
> exception I don't know about?
> >>
> >> Thanks.
> >>
> >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
> >> In the case of singletons there's very little difference, but (as I now
> see Christian has pointed out), with sequences the effect is quite
> different.
> >>
> >> Also, of course, "!" changes the context item, so
> >>
> >> @address => replace(@postcode, "", "q") works, while
> >>
> >> @address ! replace(@postcode, "", "q") doesn't.
> >>
> >> Michael Kay
> >> Saxonica
> >>
> >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Is there any advantage to using the 3.1 arrow operator over the simple
> map operator?
> >>>
> >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
> >>>
> >>> versus
> >>>
> >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> >>>
> >>> Thanks,
> >>> Wouter
> >>> _______________________________________________
> >>> talk at x-query.com
> >>> http://x-query.com/mailman/listinfo/talk
> >>
> >>
> >> _______________________________________________
> >> talk at x-query.com
> >> http://x-query.com/mailman/listinfo/talk
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170802/93a4f8bb/attachment.html>

From wshager at gmail.com  Wed Aug  2 03:09:42 2017
From: wshager at gmail.com (W.S. Hager)
Date: Wed, 2 Aug 2017 12:09:42 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
Message-ID: <CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>

That's why, for cases where it's possible, I preferred to write the simple
mapping operator, as it's easier to read IMO.

2017-08-02 12:07 GMT+02:00 W.S. Hager <wshager at gmail.com>:

> Hi Ghislain,
>
> Alright, I forgot about fn:replace#4, but the implicit binding is
> sometimes hard to detect.
>
> Thanks.
>
>
> 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
>
>> ... I didn't get it quite right actually. In @address => string(), there
>> is no context item involved, I wrote too fast. :-)
>>
>> New attempt:
>>
>> @address ! string(.) (: explicitly passed context item :)
>> @address ! string() (: context item passed implicitly to string#0, which
>> is context-dependent)
>> @address => string() (: @address passed implicitly to string#1 as the
>> first parameter via the => operator, but string#1 is context-independent)
>> @address => string(.) (: error: string#2 does not exist :)
>>
>> Kind regards,
>> Ghislain
>>
>>
>> > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
>> >
>> > Dear Wouter,
>> >
>> > There is one more important difference on the syntactic level.
>> >
>> > With the arrow operator, the left-hand-side is implicitly bound to the
>> first parameter of the function.
>> >
>> > @address => replace(@postcode, "", "q")
>> >
>> > is the same as
>> >
>> > replace(@address, @postcode, "", "q")
>> >
>> >
>> > With the simple map operator, the context item must be explicitly
>> referred to, like so:
>> >
>> > @address ! replace(., @postcode, "", "q")
>> >
>> >
>> > What may create confusion is that some functions have several
>> signatures, some of which implicitly refer to the context item. But this is
>> a very different mechanism.
>> >
>> > For example :
>> >
>> > @address ! string(.) (: explicitly passed context item :)
>> > @address ! string() (: context item passed implicitly to string#0,
>> which is context-dependent)
>> > @address => string() (: context item passed implicitly to string#1 via
>> the => operator, but string#1 is context-independent)
>> >
>> > I hope I got it right!
>> >
>> > Kind regards,
>> > Ghislain
>> >
>> >
>> >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
>> >>
>> >> Hi Michael,
>> >>
>> >> The way you used the arrow operator in the example would be the way I
>> expected it to work, namely by explicitly addressing the context, but it
>> seems that it doesn't. It's actually implicitly binding the first argument
>> of the function on the right to the value on the left. Or is there an
>> exception I don't know about?
>> >>
>> >> Thanks.
>> >>
>> >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
>> >> In the case of singletons there's very little difference, but (as I
>> now see Christian has pointed out), with sequences the effect is quite
>> different.
>> >>
>> >> Also, of course, "!" changes the context item, so
>> >>
>> >> @address => replace(@postcode, "", "q") works, while
>> >>
>> >> @address ! replace(@postcode, "", "q") doesn't.
>> >>
>> >> Michael Kay
>> >> Saxonica
>> >>
>> >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Is there any advantage to using the 3.1 arrow operator over the
>> simple map operator?
>> >>>
>> >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
>> >>>
>> >>> versus
>> >>>
>> >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
>> >>>
>> >>> Thanks,
>> >>> Wouter
>> >>> _______________________________________________
>> >>> talk at x-query.com
>> >>> http://x-query.com/mailman/listinfo/talk
>> >>
>> >>
>> >> _______________________________________________
>> >> talk at x-query.com
>> >> http://x-query.com/mailman/listinfo/talk
>> >
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170802/dab4a68b/attachment.html>

From gfourny at inf.ethz.ch  Wed Aug  2 03:20:59 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Wed, 2 Aug 2017 10:20:59 +0000
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
Message-ID: <63295B0C-2771-46A3-A247-DE2A0C5C3A21@inf.ethz.ch>

Dear Wouter,

Yes, the first version of Mike's example (=>) uses fn:replace#4, the second version (!) uses fn:replace#3.

I am not sure what you mean with "detect" : unless I am missing something, it is always 100% clear from the syntax itself which function to use from an EQName and from the number of parameters in the function invocation. When => is used, one always needs to add 1 to the arity when looking up the function. With =>, the implicit binding always occurs and it is statically known that fn:replace#4 must be used in this case, it is a bit like a rewrite. Once the function has been looked up, it is invoked according to the semantics of a function call.

Kind regards,
Ghislain

> On 2 Aug 2017, at 12:07, W.S. Hager <wshager at gmail.com> wrote:
> 
> Hi Ghislain,
> 
> Alright, I forgot about fn:replace#4, but the implicit binding is sometimes hard to detect.
> 
> Thanks.
> 
> 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
> ... I didn't get it quite right actually. In @address => string(), there is no context item involved, I wrote too fast. :-)
> 
> New attempt:
> 
> @address ! string(.) (: explicitly passed context item :)
> @address ! string() (: context item passed implicitly to string#0, which is context-dependent)
> @address => string() (: @address passed implicitly to string#1 as the first parameter via the => operator, but string#1 is context-independent)
> @address => string(.) (: error: string#2 does not exist :)
> 
> Kind regards,
> Ghislain
> 
> 
> > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
> >
> > Dear Wouter,
> >
> > There is one more important difference on the syntactic level.
> >
> > With the arrow operator, the left-hand-side is implicitly bound to the first parameter of the function.
> >
> > @address => replace(@postcode, "", "q")
> >
> > is the same as
> >
> > replace(@address, @postcode, "", "q")
> >
> >
> > With the simple map operator, the context item must be explicitly referred to, like so:
> >
> > @address ! replace(., @postcode, "", "q")
> >
> >
> > What may create confusion is that some functions have several signatures, some of which implicitly refer to the context item. But this is a very different mechanism.
> >
> > For example :
> >
> > @address ! string(.) (: explicitly passed context item :)
> > @address ! string() (: context item passed implicitly to string#0, which is context-dependent)
> > @address => string() (: context item passed implicitly to string#1 via the => operator, but string#1 is context-independent)
> >
> > I hope I got it right!
> >
> > Kind regards,
> > Ghislain
> >
> >
> >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
> >>
> >> Hi Michael,
> >>
> >> The way you used the arrow operator in the example would be the way I expected it to work, namely by explicitly addressing the context, but it seems that it doesn't. It's actually implicitly binding the first argument of the function on the right to the value on the left. Or is there an exception I don't know about?
> >>
> >> Thanks.
> >>
> >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
> >> In the case of singletons there's very little difference, but (as I now see Christian has pointed out), with sequences the effect is quite different.
> >>
> >> Also, of course, "!" changes the context item, so
> >>
> >> @address => replace(@postcode, "", "q") works, while
> >>
> >> @address ! replace(@postcode, "", "q") doesn't.
> >>
> >> Michael Kay
> >> Saxonica
> >>
> >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Is there any advantage to using the 3.1 arrow operator over the simple map operator?
> >>>
> >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
> >>>
> >>> versus
> >>>
> >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> >>>
> >>> Thanks,
> >>> Wouter
> >>> _______________________________________________
> >>> talk at x-query.com
> >>> http://x-query.com/mailman/listinfo/talk
> >>
> >>
> >> _______________________________________________
> >> talk at x-query.com
> >> http://x-query.com/mailman/listinfo/talk
> >
> 
> 
> 
> 



From christian.gruen at gmail.com  Wed Aug  2 04:10:59 2017
From: christian.gruen at gmail.com (=?UTF-8?Q?Christian_Gr=C3=BCn?=)
Date: Wed, 2 Aug 2017 13:10:59 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
Message-ID: <CAP94bnO2Ppy=iJi3Sn-P+oBezJm1zsjHd+06ODZMROZCSaA+Zg@mail.gmail.com>

Hi Wouter,

> That's why, for cases where it's possible, I preferred to write the simple
> mapping operator, as it's easier to read IMO.

In practice, in our trainings and courses, we usually present the
arrow operator as alternative for nested functions. It turned out that
most people seem to love it. Some don?t? As it?s always the case if a
language provides more than one syntactic solution. Personally, I tend
to stick with the old-school syntax, but I switch to the arrow
operator if I believe that the too much nesting makes the code
difficult to read.

As Ghislain indicated, the semantics of the two operators differs
pretty much (although there are surely some cases in which they can
serve as equivalent alternatives). Actually, the mapping operator is
much closer to XPath steps. There are even good reasons for replacing
/ with !, e.g. if you do not want to have duplicate-free and ordered
results.

Christian


>
> 2017-08-02 12:07 GMT+02:00 W.S. Hager <wshager at gmail.com>:
>>
>> Hi Ghislain,
>>
>> Alright, I forgot about fn:replace#4, but the implicit binding is
>> sometimes hard to detect.
>>
>> Thanks.
>>
>>
>> 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
>>>
>>> ... I didn't get it quite right actually. In @address => string(), there
>>> is no context item involved, I wrote too fast. :-)
>>>
>>> New attempt:
>>>
>>> @address ! string(.) (: explicitly passed context item :)
>>> @address ! string() (: context item passed implicitly to string#0, which
>>> is context-dependent)
>>> @address => string() (: @address passed implicitly to string#1 as the
>>> first parameter via the => operator, but string#1 is context-independent)
>>> @address => string(.) (: error: string#2 does not exist :)
>>>
>>> Kind regards,
>>> Ghislain
>>>
>>>
>>> > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
>>> >
>>> > Dear Wouter,
>>> >
>>> > There is one more important difference on the syntactic level.
>>> >
>>> > With the arrow operator, the left-hand-side is implicitly bound to the
>>> > first parameter of the function.
>>> >
>>> > @address => replace(@postcode, "", "q")
>>> >
>>> > is the same as
>>> >
>>> > replace(@address, @postcode, "", "q")
>>> >
>>> >
>>> > With the simple map operator, the context item must be explicitly
>>> > referred to, like so:
>>> >
>>> > @address ! replace(., @postcode, "", "q")
>>> >
>>> >
>>> > What may create confusion is that some functions have several
>>> > signatures, some of which implicitly refer to the context item. But this is
>>> > a very different mechanism.
>>> >
>>> > For example :
>>> >
>>> > @address ! string(.) (: explicitly passed context item :)
>>> > @address ! string() (: context item passed implicitly to string#0,
>>> > which is context-dependent)
>>> > @address => string() (: context item passed implicitly to string#1 via
>>> > the => operator, but string#1 is context-independent)
>>> >
>>> > I hope I got it right!
>>> >
>>> > Kind regards,
>>> > Ghislain
>>> >
>>> >
>>> >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
>>> >>
>>> >> Hi Michael,
>>> >>
>>> >> The way you used the arrow operator in the example would be the way I
>>> >> expected it to work, namely by explicitly addressing the context, but it
>>> >> seems that it doesn't. It's actually implicitly binding the first argument
>>> >> of the function on the right to the value on the left. Or is there an
>>> >> exception I don't know about?
>>> >>
>>> >> Thanks.
>>> >>
>>> >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
>>> >> In the case of singletons there's very little difference, but (as I
>>> >> now see Christian has pointed out), with sequences the effect is quite
>>> >> different.
>>> >>
>>> >> Also, of course, "!" changes the context item, so
>>> >>
>>> >> @address => replace(@postcode, "", "q") works, while
>>> >>
>>> >> @address ! replace(@postcode, "", "q") doesn't.
>>> >>
>>> >> Michael Kay
>>> >> Saxonica
>>> >>
>>> >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> Is there any advantage to using the 3.1 arrow operator over the
>>> >>> simple map operator?
>>> >>>
>>> >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
>>> >>>
>>> >>> versus
>>> >>>
>>> >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
>>> >>>
>>> >>> Thanks,
>>> >>> Wouter
>>> >>> _______________________________________________
>>> >>> talk at x-query.com
>>> >>> http://x-query.com/mailman/listinfo/talk
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> talk at x-query.com
>>> >> http://x-query.com/mailman/listinfo/talk
>>> >
>>>
>>
>>
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From mike at saxonica.com  Wed Aug  2 04:31:37 2017
From: mike at saxonica.com (Michael Kay)
Date: Wed, 2 Aug 2017 12:31:37 +0100
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP94bnO2Ppy=iJi3Sn-P+oBezJm1zsjHd+06ODZMROZCSaA+Zg@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CAP94bnO2Ppy=iJi3Sn-P+oBezJm1zsjHd+06ODZMROZCSaA+Zg@mail.gmail.com>
Message-ID: <8542B8FB-236A-4B3F-ADBA-7AD7EF7F9938@saxonica.com>

There are even good reasons for replacing
> / with !, e.g. if you do not want to have duplicate-free and ordered
> results.
> 

Yes, I'm advising people to do that, especially after a variable reference as in 

for ... return $x/item

which hardly ever needs a sort into document order so it's better to write $x!item.

I had a case reported to me recently where $var was a sequence of three parentless element nodes and $var / item essentially randomized the order because the relative order of nodes in different trees is undefined. Much better to write $var ! item which (a) makes the result predictable, and (b) avoids the cost of an unwanted sort.

Michael Kay
Saxonica



From graydonish at gmail.com  Wed Aug  2 05:32:27 2017
From: graydonish at gmail.com (Graydon Saunders)
Date: Wed, 2 Aug 2017 08:32:27 -0400
Subject: [xquery-talk] arrow operator
In-Reply-To: <C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
Message-ID: <CAO3ciQFeHNL2vKCrTB9z4SieNNbrtRR0S8OFOMdG4zUr_pNR+A@mail.gmail.com>

The thing that convinced me I cared about the arrow operator was

(//@someFlag) => distinct-values()

since there's no other way to avoid having to make whatever lump of logic
is really there for //@someFlag the explicit operand of the
distinct-values() and I often find I want to test that the lump of logic
returns the kind and number of thing I expect before reducing the sequence
to its distinct values.  Using the arrow operator results in something
that's much nicer to read.

On Tue, Aug 1, 2017 at 12:58 PM, Michael Kay <mike at saxonica.com> wrote:

> In the case of singletons there's very little difference, but (as I now
> see Christian has pointed out), with sequences the effect is quite
> different.
>
> Also, of course, "!" changes the context item, so
>
> @address => replace(@postcode, "", "q") works, while
>
> @address ! replace(@postcode, "", "q") doesn't.
>
> Michael Kay
> Saxonica
>
> > On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
> >
> > Hi,
> >
> > Is there any advantage to using the 3.1 arrow operator over the simple
> map operator?
> >
> > $string => upper-case() => normalize-unicode() => tokenize("\s+")
> >
> > versus
> >
> > $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> >
> > Thanks,
> > Wouter
> > _______________________________________________
> > talk at x-query.com
> > http://x-query.com/mailman/listinfo/talk
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170802/169d878f/attachment.html>

From gfourny at inf.ethz.ch  Wed Aug  2 06:56:29 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Wed, 2 Aug 2017 13:56:29 +0000
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP94bnO2Ppy=iJi3Sn-P+oBezJm1zsjHd+06ODZMROZCSaA+Zg@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CAP94bnO2Ppy=iJi3Sn-P+oBezJm1zsjHd+06ODZMROZCSaA+Zg@mail.gmail.com>
Message-ID: <2D131059-C8C6-4302-8491-5D7EDEED7DB9@inf.ethz.ch>

Dear Christian,

I agree; Actually, as far as I recollect, in the initial draft for the ! operator, I had spontaneously given it the same precedence as / in the grammar. We later decided that it made sense to keep them strictly separate as it makes the semantics much clearer, especially regarding sorting and duplicate elimination.

Kind regards,
Ghislain


On 2 Aug 2017, at 13:10, Christian Gr?n <christian.gruen at gmail.com<mailto:christian.gruen at gmail.com>> wrote:

As Ghislain indicated, the semantics of the two operators differs
pretty much (although there are surely some cases in which they can
serve as equivalent alternatives). Actually, the mapping operator is
much closer to XPath steps. There are even good reasons for replacing
/ with !, e.g. if you do not want to have duplicate-free and ordered
results.

Christian

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

From gfourny at inf.ethz.ch  Wed Aug  2 07:08:54 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Wed, 2 Aug 2017 14:08:54 +0000
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
Message-ID: <CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>

Dear Wouter,

Indeed, in some cases, whether to use => or ! can be subject to a matter of taste.

To put things in perspective, => was introduced in version 3.1, together with map and array support. As far as I understand it and looking again at the specs, one of the use cases is for => to be used with maps and arrays, in an object-oriented style. The XPath and XQuery Functions and Operators 3.1 specification [1] explicitly gives a few examples:

["a", "b", "c"] => array:get(2)

$array => array:remove($position) => array:insert-before($position, $member)

Kind regards,
Ghislain

[1] https://www.w3.org/TR/xpath-functions-31/


> On 2 Aug 2017, at 12:09, W.S. Hager <wshager at gmail.com> wrote:
> 
> That's why, for cases where it's possible, I preferred to write the simple mapping operator, as it's easier to read IMO. 
> 
> 2017-08-02 12:07 GMT+02:00 W.S. Hager <wshager at gmail.com>:
> Hi Ghislain,
> 
> Alright, I forgot about fn:replace#4, but the implicit binding is sometimes hard to detect.
> 
> Thanks.
> 
> 
> 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
> ... I didn't get it quite right actually. In @address => string(), there is no context item involved, I wrote too fast. :-)
> 
> New attempt:
> 
> @address ! string(.) (: explicitly passed context item :)
> @address ! string() (: context item passed implicitly to string#0, which is context-dependent)
> @address => string() (: @address passed implicitly to string#1 as the first parameter via the => operator, but string#1 is context-independent)
> @address => string(.) (: error: string#2 does not exist :)
> 
> Kind regards,
> Ghislain
> 
> 
> > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
> >
> > Dear Wouter,
> >
> > There is one more important difference on the syntactic level.
> >
> > With the arrow operator, the left-hand-side is implicitly bound to the first parameter of the function.
> >
> > @address => replace(@postcode, "", "q")
> >
> > is the same as
> >
> > replace(@address, @postcode, "", "q")
> >
> >
> > With the simple map operator, the context item must be explicitly referred to, like so:
> >
> > @address ! replace(., @postcode, "", "q")
> >
> >
> > What may create confusion is that some functions have several signatures, some of which implicitly refer to the context item. But this is a very different mechanism.
> >
> > For example :
> >
> > @address ! string(.) (: explicitly passed context item :)
> > @address ! string() (: context item passed implicitly to string#0, which is context-dependent)
> > @address => string() (: context item passed implicitly to string#1 via the => operator, but string#1 is context-independent)
> >
> > I hope I got it right!
> >
> > Kind regards,
> > Ghislain
> >
> >
> >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
> >>
> >> Hi Michael,
> >>
> >> The way you used the arrow operator in the example would be the way I expected it to work, namely by explicitly addressing the context, but it seems that it doesn't. It's actually implicitly binding the first argument of the function on the right to the value on the left. Or is there an exception I don't know about?
> >>
> >> Thanks.
> >>
> >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
> >> In the case of singletons there's very little difference, but (as I now see Christian has pointed out), with sequences the effect is quite different.
> >>
> >> Also, of course, "!" changes the context item, so
> >>
> >> @address => replace(@postcode, "", "q") works, while
> >>
> >> @address ! replace(@postcode, "", "q") doesn't.
> >>
> >> Michael Kay
> >> Saxonica
> >>
> >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Is there any advantage to using the 3.1 arrow operator over the simple map operator?
> >>>
> >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
> >>>
> >>> versus
> >>>
> >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> >>>
> >>> Thanks,
> >>> Wouter
> >>> _______________________________________________
> >>> talk at x-query.com
> >>> http://x-query.com/mailman/listinfo/talk
> >>
> >>
> >> _______________________________________________
> >> talk at x-query.com
> >> http://x-query.com/mailman/listinfo/talk
> >
> 
> 
> 
> 
> 
> 



From wshager at gmail.com  Wed Aug  2 07:17:04 2017
From: wshager at gmail.com (W.S. Hager)
Date: Wed, 2 Aug 2017 16:17:04 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
Message-ID: <CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>

Dear Ghislain,

This I understand, but the only thing that bothers me is that the implicit
binding of the first argument prevents the use of other arguments, whereas
an explicit context would've allowed for the more flexible option of
designating the argument yourself, while the arity would read more clearly:

$position => array:remove($array, .)

This difference with the simple mapping operator is what confuses and
surprises me, but it seems I'm the only one, so let's just leave it at that.

Thanks a lot for your time.

Wouter

2017-08-02 16:08 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:

> Dear Wouter,
>
> Indeed, in some cases, whether to use => or ! can be subject to a matter
> of taste.
>
> To put things in perspective, => was introduced in version 3.1, together
> with map and array support. As far as I understand it and looking again at
> the specs, one of the use cases is for => to be used with maps and arrays,
> in an object-oriented style. The XPath and XQuery Functions and Operators
> 3.1 specification [1] explicitly gives a few examples:
>
> ["a", "b", "c"] => array:get(2)
>
> $array => array:remove($position) => array:insert-before($position,
> $member)
>
> Kind regards,
> Ghislain
>
> [1] https://www.w3.org/TR/xpath-functions-31/
>
>
> > On 2 Aug 2017, at 12:09, W.S. Hager <wshager at gmail.com> wrote:
> >
> > That's why, for cases where it's possible, I preferred to write the
> simple mapping operator, as it's easier to read IMO.
> >
> > 2017-08-02 12:07 GMT+02:00 W.S. Hager <wshager at gmail.com>:
> > Hi Ghislain,
> >
> > Alright, I forgot about fn:replace#4, but the implicit binding is
> sometimes hard to detect.
> >
> > Thanks.
> >
> >
> > 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
> > ... I didn't get it quite right actually. In @address => string(), there
> is no context item involved, I wrote too fast. :-)
> >
> > New attempt:
> >
> > @address ! string(.) (: explicitly passed context item :)
> > @address ! string() (: context item passed implicitly to string#0, which
> is context-dependent)
> > @address => string() (: @address passed implicitly to string#1 as the
> first parameter via the => operator, but string#1 is context-independent)
> > @address => string(.) (: error: string#2 does not exist :)
> >
> > Kind regards,
> > Ghislain
> >
> >
> > > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
> > >
> > > Dear Wouter,
> > >
> > > There is one more important difference on the syntactic level.
> > >
> > > With the arrow operator, the left-hand-side is implicitly bound to the
> first parameter of the function.
> > >
> > > @address => replace(@postcode, "", "q")
> > >
> > > is the same as
> > >
> > > replace(@address, @postcode, "", "q")
> > >
> > >
> > > With the simple map operator, the context item must be explicitly
> referred to, like so:
> > >
> > > @address ! replace(., @postcode, "", "q")
> > >
> > >
> > > What may create confusion is that some functions have several
> signatures, some of which implicitly refer to the context item. But this is
> a very different mechanism.
> > >
> > > For example :
> > >
> > > @address ! string(.) (: explicitly passed context item :)
> > > @address ! string() (: context item passed implicitly to string#0,
> which is context-dependent)
> > > @address => string() (: context item passed implicitly to string#1 via
> the => operator, but string#1 is context-independent)
> > >
> > > I hope I got it right!
> > >
> > > Kind regards,
> > > Ghislain
> > >
> > >
> > >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
> > >>
> > >> Hi Michael,
> > >>
> > >> The way you used the arrow operator in the example would be the way I
> expected it to work, namely by explicitly addressing the context, but it
> seems that it doesn't. It's actually implicitly binding the first argument
> of the function on the right to the value on the left. Or is there an
> exception I don't know about?
> > >>
> > >> Thanks.
> > >>
> > >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
> > >> In the case of singletons there's very little difference, but (as I
> now see Christian has pointed out), with sequences the effect is quite
> different.
> > >>
> > >> Also, of course, "!" changes the context item, so
> > >>
> > >> @address => replace(@postcode, "", "q") works, while
> > >>
> > >> @address ! replace(@postcode, "", "q") doesn't.
> > >>
> > >> Michael Kay
> > >> Saxonica
> > >>
> > >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Is there any advantage to using the 3.1 arrow operator over the
> simple map operator?
> > >>>
> > >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
> > >>>
> > >>> versus
> > >>>
> > >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> > >>>
> > >>> Thanks,
> > >>> Wouter
> > >>> _______________________________________________
> > >>> talk at x-query.com
> > >>> http://x-query.com/mailman/listinfo/talk
> > >>
> > >>
> > >> _______________________________________________
> > >> talk at x-query.com
> > >> http://x-query.com/mailman/listinfo/talk
> > >
> >
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170802/bb802cbe/attachment.html>

From wshager at gmail.com  Wed Aug  2 07:22:52 2017
From: wshager at gmail.com (W.S. Hager)
Date: Wed, 2 Aug 2017 16:22:52 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>
Message-ID: <CAP8fv=3+_zx0ORoV8NM1Uxb8QFzkuG9MDT4wfB6ZUR=Hc=DTMA@mail.gmail.com>

To be precise, I think it means that the context needs to be bound to the
result of the left side of the arrow, but perhaps that isn't even possible.
Anyway, the convention seems to me just as trivial as binding the first
argument.



2017-08-02 16:17 GMT+02:00 W.S. Hager <wshager at gmail.com>:

> Dear Ghislain,
>
> This I understand, but the only thing that bothers me is that the implicit
> binding of the first argument prevents the use of other arguments, whereas
> an explicit context would've allowed for the more flexible option of
> designating the argument yourself, while the arity would read more clearly:
>
> $position => array:remove($array, .)
>
> This difference with the simple mapping operator is what confuses and
> surprises me, but it seems I'm the only one, so let's just leave it at that.
>
> Thanks a lot for your time.
>
> Wouter
>
>
> 2017-08-02 16:08 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
>
>> Dear Wouter,
>>
>> Indeed, in some cases, whether to use => or ! can be subject to a matter
>> of taste.
>>
>> To put things in perspective, => was introduced in version 3.1, together
>> with map and array support. As far as I understand it and looking again at
>> the specs, one of the use cases is for => to be used with maps and arrays,
>> in an object-oriented style. The XPath and XQuery Functions and Operators
>> 3.1 specification [1] explicitly gives a few examples:
>>
>> ["a", "b", "c"] => array:get(2)
>>
>> $array => array:remove($position) => array:insert-before($position,
>> $member)
>>
>> Kind regards,
>> Ghislain
>>
>> [1] https://www.w3.org/TR/xpath-functions-31/
>>
>>
>> > On 2 Aug 2017, at 12:09, W.S. Hager <wshager at gmail.com> wrote:
>> >
>> > That's why, for cases where it's possible, I preferred to write the
>> simple mapping operator, as it's easier to read IMO.
>> >
>> > 2017-08-02 12:07 GMT+02:00 W.S. Hager <wshager at gmail.com>:
>> > Hi Ghislain,
>> >
>> > Alright, I forgot about fn:replace#4, but the implicit binding is
>> sometimes hard to detect.
>> >
>> > Thanks.
>> >
>> >
>> > 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
>> > ... I didn't get it quite right actually. In @address => string(),
>> there is no context item involved, I wrote too fast. :-)
>> >
>> > New attempt:
>> >
>> > @address ! string(.) (: explicitly passed context item :)
>> > @address ! string() (: context item passed implicitly to string#0,
>> which is context-dependent)
>> > @address => string() (: @address passed implicitly to string#1 as the
>> first parameter via the => operator, but string#1 is context-independent)
>> > @address => string(.) (: error: string#2 does not exist :)
>> >
>> > Kind regards,
>> > Ghislain
>> >
>> >
>> > > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
>> > >
>> > > Dear Wouter,
>> > >
>> > > There is one more important difference on the syntactic level.
>> > >
>> > > With the arrow operator, the left-hand-side is implicitly bound to
>> the first parameter of the function.
>> > >
>> > > @address => replace(@postcode, "", "q")
>> > >
>> > > is the same as
>> > >
>> > > replace(@address, @postcode, "", "q")
>> > >
>> > >
>> > > With the simple map operator, the context item must be explicitly
>> referred to, like so:
>> > >
>> > > @address ! replace(., @postcode, "", "q")
>> > >
>> > >
>> > > What may create confusion is that some functions have several
>> signatures, some of which implicitly refer to the context item. But this is
>> a very different mechanism.
>> > >
>> > > For example :
>> > >
>> > > @address ! string(.) (: explicitly passed context item :)
>> > > @address ! string() (: context item passed implicitly to string#0,
>> which is context-dependent)
>> > > @address => string() (: context item passed implicitly to string#1
>> via the => operator, but string#1 is context-independent)
>> > >
>> > > I hope I got it right!
>> > >
>> > > Kind regards,
>> > > Ghislain
>> > >
>> > >
>> > >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
>> > >>
>> > >> Hi Michael,
>> > >>
>> > >> The way you used the arrow operator in the example would be the way
>> I expected it to work, namely by explicitly addressing the context, but it
>> seems that it doesn't. It's actually implicitly binding the first argument
>> of the function on the right to the value on the left. Or is there an
>> exception I don't know about?
>> > >>
>> > >> Thanks.
>> > >>
>> > >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
>> > >> In the case of singletons there's very little difference, but (as I
>> now see Christian has pointed out), with sequences the effect is quite
>> different.
>> > >>
>> > >> Also, of course, "!" changes the context item, so
>> > >>
>> > >> @address => replace(@postcode, "", "q") works, while
>> > >>
>> > >> @address ! replace(@postcode, "", "q") doesn't.
>> > >>
>> > >> Michael Kay
>> > >> Saxonica
>> > >>
>> > >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
>> > >>>
>> > >>> Hi,
>> > >>>
>> > >>> Is there any advantage to using the 3.1 arrow operator over the
>> simple map operator?
>> > >>>
>> > >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
>> > >>>
>> > >>> versus
>> > >>>
>> > >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
>> > >>>
>> > >>> Thanks,
>> > >>> Wouter
>> > >>> _______________________________________________
>> > >>> talk at x-query.com
>> > >>> http://x-query.com/mailman/listinfo/talk
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> talk at x-query.com
>> > >> http://x-query.com/mailman/listinfo/talk
>> > >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170802/d02012f9/attachment.html>

From christian.gruen at gmail.com  Wed Aug  2 07:30:14 2017
From: christian.gruen at gmail.com (=?UTF-8?Q?Christian_Gr=C3=BCn?=)
Date: Wed, 2 Aug 2017 16:30:14 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>
Message-ID: <CAP94bnNqoFcJqZYq7Pp+EZ9krOkzZATtAg=PC_9EughyZ5kPBA@mail.gmail.com>

> This I understand, but the only thing that bothers me is that the implicit
> binding of the first argument prevents the use of other arguments, whereas
> an explicit context would've allowed for the more flexible option of
> designating the argument yourself, while the arity would read more clearly:
>
> $position => array:remove($array, .)

A similar proposal was discussed in the W3 Bugzilla tracker some time ago:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

The majority of the W3 members voted for the initial proposal.

Here is yet another related idea that ended up in the 3.2 backlog:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=29393



> 2017-08-02 16:08 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
>>
>> Dear Wouter,
>>
>> Indeed, in some cases, whether to use => or ! can be subject to a matter
>> of taste.
>>
>> To put things in perspective, => was introduced in version 3.1, together
>> with map and array support. As far as I understand it and looking again at
>> the specs, one of the use cases is for => to be used with maps and arrays,
>> in an object-oriented style. The XPath and XQuery Functions and Operators
>> 3.1 specification [1] explicitly gives a few examples:
>>
>> ["a", "b", "c"] => array:get(2)
>>
>> $array => array:remove($position) => array:insert-before($position,
>> $member)
>>
>> Kind regards,
>> Ghislain
>>
>> [1] https://www.w3.org/TR/xpath-functions-31/
>>
>>
>> > On 2 Aug 2017, at 12:09, W.S. Hager <wshager at gmail.com> wrote:
>> >
>> > That's why, for cases where it's possible, I preferred to write the
>> > simple mapping operator, as it's easier to read IMO.
>> >
>> > 2017-08-02 12:07 GMT+02:00 W.S. Hager <wshager at gmail.com>:
>> > Hi Ghislain,
>> >
>> > Alright, I forgot about fn:replace#4, but the implicit binding is
>> > sometimes hard to detect.
>> >
>> > Thanks.
>> >
>> >
>> > 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
>> > ... I didn't get it quite right actually. In @address => string(), there
>> > is no context item involved, I wrote too fast. :-)
>> >
>> > New attempt:
>> >
>> > @address ! string(.) (: explicitly passed context item :)
>> > @address ! string() (: context item passed implicitly to string#0, which
>> > is context-dependent)
>> > @address => string() (: @address passed implicitly to string#1 as the
>> > first parameter via the => operator, but string#1 is context-independent)
>> > @address => string(.) (: error: string#2 does not exist :)
>> >
>> > Kind regards,
>> > Ghislain
>> >
>> >
>> > > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch> wrote:
>> > >
>> > > Dear Wouter,
>> > >
>> > > There is one more important difference on the syntactic level.
>> > >
>> > > With the arrow operator, the left-hand-side is implicitly bound to the
>> > > first parameter of the function.
>> > >
>> > > @address => replace(@postcode, "", "q")
>> > >
>> > > is the same as
>> > >
>> > > replace(@address, @postcode, "", "q")
>> > >
>> > >
>> > > With the simple map operator, the context item must be explicitly
>> > > referred to, like so:
>> > >
>> > > @address ! replace(., @postcode, "", "q")
>> > >
>> > >
>> > > What may create confusion is that some functions have several
>> > > signatures, some of which implicitly refer to the context item. But this is
>> > > a very different mechanism.
>> > >
>> > > For example :
>> > >
>> > > @address ! string(.) (: explicitly passed context item :)
>> > > @address ! string() (: context item passed implicitly to string#0,
>> > > which is context-dependent)
>> > > @address => string() (: context item passed implicitly to string#1 via
>> > > the => operator, but string#1 is context-independent)
>> > >
>> > > I hope I got it right!
>> > >
>> > > Kind regards,
>> > > Ghislain
>> > >
>> > >
>> > >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com> wrote:
>> > >>
>> > >> Hi Michael,
>> > >>
>> > >> The way you used the arrow operator in the example would be the way I
>> > >> expected it to work, namely by explicitly addressing the context, but it
>> > >> seems that it doesn't. It's actually implicitly binding the first argument
>> > >> of the function on the right to the value on the left. Or is there an
>> > >> exception I don't know about?
>> > >>
>> > >> Thanks.
>> > >>
>> > >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com>:
>> > >> In the case of singletons there's very little difference, but (as I
>> > >> now see Christian has pointed out), with sequences the effect is quite
>> > >> different.
>> > >>
>> > >> Also, of course, "!" changes the context item, so
>> > >>
>> > >> @address => replace(@postcode, "", "q") works, while
>> > >>
>> > >> @address ! replace(@postcode, "", "q") doesn't.
>> > >>
>> > >> Michael Kay
>> > >> Saxonica
>> > >>
>> > >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com> wrote:
>> > >>>
>> > >>> Hi,
>> > >>>
>> > >>> Is there any advantage to using the 3.1 arrow operator over the
>> > >>> simple map operator?
>> > >>>
>> > >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
>> > >>>
>> > >>> versus
>> > >>>
>> > >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
>> > >>>
>> > >>> Thanks,
>> > >>> Wouter
>> > >>> _______________________________________________
>> > >>> talk at x-query.com
>> > >>> http://x-query.com/mailman/listinfo/talk
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> talk at x-query.com
>> > >> http://x-query.com/mailman/listinfo/talk
>> > >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

From gfourny at inf.ethz.ch  Wed Aug  2 07:31:19 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Wed, 2 Aug 2017 14:31:19 +0000
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=3+_zx0ORoV8NM1Uxb8QFzkuG9MDT4wfB6ZUR=Hc=DTMA@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>
	<CAP8fv=3+_zx0ORoV8NM1Uxb8QFzkuG9MDT4wfB6ZUR=Hc=DTMA@mail.gmail.com>
Message-ID: <B33F8146-3C40-4B3D-9C1F-F3EB9B0449B7@inf.ethz.ch>

Dear Wouter,

I see your point and it makes sense. The tricky part here, following up on your suggestion to make the choice of the first position less arbitrary, is that the context item must be an item: it cannot be a sequence of several items. This eliminates any design based on communicating the value on the left through the context item mechanism. The closest to the intent of => would be using a let variable binding.

The convention of binding the first argument, of course, implies that the (or some) functions are designed having in mind that the first parameter is ?special?, that is, if the function is intended to be used with =>. In Java or C++, the self/this implied parameter is special, too (but it is not considered to be at any position).

Kind regards,
Ghislain


On 2 Aug 2017, at 16:22, W.S. Hager <wshager at gmail.com<mailto:wshager at gmail.com>> wrote:

To be precise, I think it means that the context needs to be bound to the result of the left side of the arrow, but perhaps that isn't even possible. Anyway, the convention seems to me just as trivial as binding the first argument.



2017-08-02 16:17 GMT+02:00 W.S. Hager <wshager at gmail.com<mailto:wshager at gmail.com>>:
Dear Ghislain,

This I understand, but the only thing that bothers me is that the implicit binding of the first argument prevents the use of other arguments, whereas an explicit context would've allowed for the more flexible option of designating the argument yourself, while the arity would read more clearly:

$position => array:remove($array, .)

This difference with the simple mapping operator is what confuses and surprises me, but it seems I'm the only one, so let's just leave it at that.

Thanks a lot for your time.

Wouter


2017-08-02 16:08 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch<mailto:gfourny at inf.ethz.ch>>:
Dear Wouter,

Indeed, in some cases, whether to use => or ! can be subject to a matter of taste.

To put things in perspective, => was introduced in version 3.1, together with map and array support. As far as I understand it and looking again at the specs, one of the use cases is for => to be used with maps and arrays, in an object-oriented style. The XPath and XQuery Functions and Operators 3.1 specification [1] explicitly gives a few examples:

["a", "b", "c"] => array:get(2)

$array => array:remove($position) => array:insert-before($position, $member)

Kind regards,
Ghislain

[1] https://www.w3.org/TR/xpath-functions-31/


> On 2 Aug 2017, at 12:09, W.S. Hager <wshager at gmail.com<mailto:wshager at gmail.com>> wrote:
>
> That's why, for cases where it's possible, I preferred to write the simple mapping operator, as it's easier to read IMO.
>
> 2017-08-02 12:07 GMT+02:00 W.S. Hager <wshager at gmail.com<mailto:wshager at gmail.com>>:
> Hi Ghislain,
>
> Alright, I forgot about fn:replace#4, but the implicit binding is sometimes hard to detect.
>
> Thanks.
>
>
> 2017-08-02 12:04 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch<mailto:gfourny at inf.ethz.ch>>:
> ... I didn't get it quite right actually. In @address => string(), there is no context item involved, I wrote too fast. :-)
>
> New attempt:
>
> @address ! string(.) (: explicitly passed context item :)
> @address ! string() (: context item passed implicitly to string#0, which is context-dependent)
> @address => string() (: @address passed implicitly to string#1 as the first parameter via the => operator, but string#1 is context-independent)
> @address => string(.) (: error: string#2 does not exist :)
>
> Kind regards,
> Ghislain
>
>
> > On 2 Aug 2017, at 12:00, Ghislain Fourny <gfourny at inf.ethz.ch<mailto:gfourny at inf.ethz.ch>> wrote:
> >
> > Dear Wouter,
> >
> > There is one more important difference on the syntactic level.
> >
> > With the arrow operator, the left-hand-side is implicitly bound to the first parameter of the function.
> >
> > @address => replace(@postcode, "", "q")
> >
> > is the same as
> >
> > replace(@address, @postcode, "", "q")
> >
> >
> > With the simple map operator, the context item must be explicitly referred to, like so:
> >
> > @address ! replace(., @postcode, "", "q")
> >
> >
> > What may create confusion is that some functions have several signatures, some of which implicitly refer to the context item. But this is a very different mechanism.
> >
> > For example :
> >
> > @address ! string(.) (: explicitly passed context item :)
> > @address ! string() (: context item passed implicitly to string#0, which is context-dependent)
> > @address => string() (: context item passed implicitly to string#1 via the => operator, but string#1 is context-independent)
> >
> > I hope I got it right!
> >
> > Kind regards,
> > Ghislain
> >
> >
> >> On 2 Aug 2017, at 11:27, W.S. Hager <wshager at gmail.com<mailto:wshager at gmail.com>> wrote:
> >>
> >> Hi Michael,
> >>
> >> The way you used the arrow operator in the example would be the way I expected it to work, namely by explicitly addressing the context, but it seems that it doesn't. It's actually implicitly binding the first argument of the function on the right to the value on the left. Or is there an exception I don't know about?
> >>
> >> Thanks.
> >>
> >> Op 1 aug. 2017 18:58 schreef "Michael Kay" <mike at saxonica.com<mailto:mike at saxonica.com>>:
> >> In the case of singletons there's very little difference, but (as I now see Christian has pointed out), with sequences the effect is quite different.
> >>
> >> Also, of course, "!" changes the context item, so
> >>
> >> @address => replace(@postcode, "", "q") works, while
> >>
> >> @address ! replace(@postcode, "", "q") doesn't.
> >>
> >> Michael Kay
> >> Saxonica
> >>
> >>> On 1 Aug 2017, at 13:27, W.S. Hager <wshager at gmail.com<mailto:wshager at gmail.com>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Is there any advantage to using the 3.1 arrow operator over the simple map operator?
> >>>
> >>> $string => upper-case() => normalize-unicode() => tokenize("\s+")
> >>>
> >>> versus
> >>>
> >>> $string ! upper-case(.) ! normalize-unicode(.) ! tokenize(.,"\s+")
> >>>
> >>> Thanks,
> >>> Wouter
> >>> _______________________________________________
> >>> talk at x-query.com<mailto:talk at x-query.com>
> >>> http://x-query.com/mailman/listinfo/talk
> >>
> >>
> >> _______________________________________________
> >> talk at x-query.com<mailto:talk at x-query.com>
> >> http://x-query.com/mailman/listinfo/talk
> >
>
>
>
>
>
>






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

From wshager at gmail.com  Wed Aug  2 07:57:00 2017
From: wshager at gmail.com (W.S. Hager)
Date: Wed, 2 Aug 2017 16:57:00 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <B33F8146-3C40-4B3D-9C1F-F3EB9B0449B7@inf.ethz.ch>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>
	<CAP8fv=3+_zx0ORoV8NM1Uxb8QFzkuG9MDT4wfB6ZUR=Hc=DTMA@mail.gmail.com>
	<B33F8146-3C40-4B3D-9C1F-F3EB9B0449B7@inf.ethz.ch>
Message-ID: <CAP8fv=3A8jbe3-_rYdG4Xc+=nTeZ1iaa-qO6+1N=WhPWYZmSGQ@mail.gmail.com>

Why can't the context contain a sequence?


2017-08-02 16:31 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:

> Dear Wouter,
>
> I see your point and it makes sense. The tricky part here, following up on
> your suggestion to make the choice of the first position less arbitrary, is
> that the context item must be an item: it cannot be a sequence of several
> items. This eliminates any design based on communicating the value on the
> left through the context item mechanism. The closest to the intent of =>
> would be using a let variable binding.
>
> The convention of binding the first argument, of course, implies that the
> (or some) functions are designed having in mind that the first parameter is
> ?special?, that is, if the function is intended to be used with =>. In Java
> or C++, the self/this implied parameter is special, too (but it is not
> considered to be at any position).
>
> Kind regards,
> Ghislain
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170802/7db96490/attachment.html>

From christian.gruen at gmail.com  Wed Aug  2 08:01:45 2017
From: christian.gruen at gmail.com (=?UTF-8?Q?Christian_Gr=C3=BCn?=)
Date: Wed, 2 Aug 2017 17:01:45 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=3A8jbe3-_rYdG4Xc+=nTeZ1iaa-qO6+1N=WhPWYZmSGQ@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<CAP8fv=3Ht0SkM+MkevhEY9jVoaaw0JkOg6zB=feZyUcu2kwdig@mail.gmail.com>
	<CAP8fv=3+_zx0ORoV8NM1Uxb8QFzkuG9MDT4wfB6ZUR=Hc=DTMA@mail.gmail.com>
	<B33F8146-3C40-4B3D-9C1F-F3EB9B0449B7@inf.ethz.ch>
	<CAP8fv=3A8jbe3-_rYdG4Xc+=nTeZ1iaa-qO6+1N=WhPWYZmSGQ@mail.gmail.com>
Message-ID: <CAP94bnPxWhJGfnzN3TNBVMRUoM_yFPOW5Oa9UYjArHmA1jVunA@mail.gmail.com>

> Why can't the context contain a sequence?

Please have a look at the specification for more information on the
context item:

  https://www.w3.org/TR/xquery-31/#dt-context-item




> 2017-08-02 16:31 GMT+02:00 Ghislain Fourny <gfourny at inf.ethz.ch>:
>>
>> Dear Wouter,
>>
>> I see your point and it makes sense. The tricky part here, following up on
>> your suggestion to make the choice of the first position less arbitrary, is
>> that the context item must be an item: it cannot be a sequence of several
>> items. This eliminates any design based on communicating the value on the
>> left through the context item mechanism. The closest to the intent of =>
>> would be using a let variable binding.
>>
>> The convention of binding the first argument, of course, implies that the
>> (or some) functions are designed having in mind that the first parameter is
>> ?special?, that is, if the function is intended to be used with =>. In Java
>> or C++, the self/this implied parameter is special, too (but it is not
>> considered to be at any position).
>>
>> Kind regards,
>> Ghislain
>>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk


From mike at saxonica.com  Wed Aug  2 08:44:32 2017
From: mike at saxonica.com (Michael Kay)
Date: Wed, 2 Aug 2017 16:44:32 +0100
Subject: [xquery-talk] arrow operator
In-Reply-To: <CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
Message-ID: <D7644C40-5FE5-47F4-B744-55A8EAF35AB1@saxonica.com>

> 
> To put things in perspective, => was introduced in version 3.1, together with map and array support. As far as I understand it and looking again at the specs, one of the use cases is for => to be used with maps and arrays, in an object-oriented style.


In particular, arrays don't have a filter operator in the way that sequences do, neither do they have a mapping operator, so to select into an array of maps you need to do things like

$A => a:filter( function($m) {$m?name='Mike'}) => a:for-each( function($m) { $m?age })

which gets terribly unwieldy if you try to write it with conventional nested function calls.

I wish we had done a concise anonymous function declaration as well:

$A => a:filter( {?name='Mike'} ) => a:for-each( {?age} )

Here {EXPR} is shorthand for "function($x){ $x ! EXPR }"
 
but that would have been a bridge too far for some people.

Michael Kay
Saxonica



 

From wshager at gmail.com  Thu Aug  3 12:46:23 2017
From: wshager at gmail.com (W.S. Hager)
Date: Thu, 3 Aug 2017 21:46:23 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <D7644C40-5FE5-47F4-B744-55A8EAF35AB1@saxonica.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<D7644C40-5FE5-47F4-B744-55A8EAF35AB1@saxonica.com>
Message-ID: <CAP8fv=3y4UUrg_OkT5kSx__=uMCvOsYDcfYw1L48FbbfA7qBvQ@mail.gmail.com>

Hi Michael,

Anonymous functions would've been quite nice, but could your example only
be used for a single argument?

Op 2 aug. 2017 17:44 schreef "Michael Kay" <mike at saxonica.com>:

>
> To put things in perspective, => was introduced in version 3.1, together
with map and array support. As far as I understand it and looking again at
the specs, one of the use cases is for => to be used with maps and arrays,
in an object-oriented style.


In particular, arrays don't have a filter operator in the way that
sequences do, neither do they have a mapping operator, so to select into an
array of maps you need to do things like

$A => a:filter( function($m) {$m?name='Mike'}) => a:for-each( function($m)
{ $m?age })

which gets terribly unwieldy if you try to write it with conventional
nested function calls.

I wish we had done a concise anonymous function declaration as well:

$A => a:filter( {?name='Mike'} ) => a:for-each( {?age} )

Here {EXPR} is shorthand for "function($x){ $x ! EXPR }"

but that would have been a bridge too far for some people.

Michael Kay
Saxonica
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170803/2768b726/attachment.html>

From mike at saxonica.com  Thu Aug  3 14:01:21 2017
From: mike at saxonica.com (Michael Kay)
Date: Thu, 3 Aug 2017 22:01:21 +0100
Subject: [xquery-talk] arrow operator
In-Reply-To: <CAP8fv=3y4UUrg_OkT5kSx__=uMCvOsYDcfYw1L48FbbfA7qBvQ@mail.gmail.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<D7644C40-5FE5-47F4-B744-55A8EAF35AB1@saxonica.com>
	<CAP8fv=3y4UUrg_OkT5kSx__=uMCvOsYDcfYw1L48FbbfA7qBvQ@mail.gmail.com>
Message-ID: <104BD7FE-29A6-494A-84B0-E0C72204DBDD@saxonica.com>

> 
> Anonymous functions would've been quite nice, but could your example only be used for a single argument?

Yes. I think that's such a common case that it's worth having special syntax for, particularly as we already have "." as a symbol representing an anonymous variable, so we get a nice combination of concepts.

(We do of course have syntax for the more general case already: it's just a bit verbose.)

But of course, in the WG we would spend months discussing alternatives and might well come up with something better...

Michael Kay
Saxonica

From wshager at gmail.com  Fri Aug  4 00:52:59 2017
From: wshager at gmail.com (W.S. Hager)
Date: Fri, 4 Aug 2017 09:52:59 +0200
Subject: [xquery-talk] arrow operator
In-Reply-To: <104BD7FE-29A6-494A-84B0-E0C72204DBDD@saxonica.com>
References: <CAP8fv=1-Ykoq0DQMkirUezjUKsC=31HEVx3FcGhJ_LZeBAopkQ@mail.gmail.com>
	<C0EC95A4-F6A3-4D19-AB71-A2E4F26A34B3@saxonica.com>
	<CAP8fv=0A05H=TVtPGv3ucGjcCpzU-VuWQ0P+-M6xzd66FWONmw@mail.gmail.com>
	<DCFA5952-EEC4-400F-8A3D-71DA4C033C33@inf.ethz.ch>
	<D5B812DB-16CD-4018-9362-C41734692B6B@inf.ethz.ch>
	<CAP8fv=1N3yrR0_rMo=Er7J1Nf7fHCBvZAK7G7EU7q1gO22rehQ@mail.gmail.com>
	<CAP8fv=0Ait=--0SiPHQD=dx+p1XCW+n4HX49QO6RzGq1g_s0bA@mail.gmail.com>
	<CF87B0F8-B9E2-4BD3-A6F5-306B719A9DE3@inf.ethz.ch>
	<D7644C40-5FE5-47F4-B744-55A8EAF35AB1@saxonica.com>
	<CAP8fv=3y4UUrg_OkT5kSx__=uMCvOsYDcfYw1L48FbbfA7qBvQ@mail.gmail.com>
	<104BD7FE-29A6-494A-84B0-E0C72204DBDD@saxonica.com>
Message-ID: <CAP8fv=1Wu5xvE62LJmOvbJ7h0DHjJK32G31Rj_yvNjKTOd0cMQ@mail.gmail.com>

I see, thanks.

Op 3 aug. 2017 23:01 schreef "Michael Kay" <mike at saxonica.com>:

> >
> > Anonymous functions would've been quite nice, but could your example
> only be used for a single argument?
>
> Yes. I think that's such a common case that it's worth having special
> syntax for, particularly as we already have "." as a symbol representing an
> anonymous variable, so we get a nice combination of concepts.
>
> (We do of course have syntax for the more general case already: it's just
> a bit verbose.)
>
> But of course, in the WG we would spend months discussing alternatives and
> might well come up with something better...
>
> Michael Kay
> Saxonica
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170804/ee78bbdd/attachment.html>

From xquery at docbook-autor.de  Wed Aug  9 23:07:55 2017
From: xquery at docbook-autor.de (xquery at docbook-autor.de)
Date: Thu, 10 Aug 2017 08:07:55 +0200
Subject: [xquery-talk] SQL to XML with XQuery?
Message-ID: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>


 Hi,

I know that XQuery is typically used for transforming XML into other
text file formats.

But is it possible to use XQuery for the other way round?

I want to transform a very simple SQL Create Table statement into XML.


SQL
===

CREATE TABLE mytable1

(
  FIELD1	xxx;
  FIELD2	xxx;
  FIELD3	xxx;
);

COMMENT ON COLUMN mytable1.FIELD1 'Description1';
COMMENT ON COLUMN mytable1.FIELD2 'Description2';

CREATE TABLE mytable2

(
  FIELD1	xxx;
  FIELD2	xxx;
  FIELD3	xxx;
);

COMMENT ON COLUMN mytable2.FIELD1 'Description1';
COMMENT ON COLUMN mytable2.FIELD3 'Description3';


XML
===

<table>
  <title>mytable1</title>
  <column>
    <name>FIELD1</name>
    <comment>Description1</comment>
  </column>
  <column>
    <name>FIELD2</name>
    <comment>Description2</comment>
  </column>
  <column>
    <name>FIELD1</name>
    <comment></comment>
  </column>
</table>

<table>
  <title>mytable2</title>
  <column>
    <name>FIELD1</name>
    <comment>Description1</comment>
  </column>
  <column>
    <name>FIELD2</name>
    <comment></comment>
  </column>
  <column>
    <name>FIELD1</name>
    <comment>Description3</comment>
  </column>
</table>

Can this be done via XQuery? If not which tool could possibly fit my needs?

Best regards
Michael

From ihe.onwuka at gmail.com  Wed Aug  9 23:13:42 2017
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 10 Aug 2017 02:13:42 -0400
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
Message-ID: <CALfs7+xCNNvoffEyLz9fhdQJqQc8EQ99SY__4rJ6=QOyYgSHqg@mail.gmail.com>

DB2 version 10 onwards lets you mix SQL and XQuery commands in one query.

On Thu, Aug 10, 2017 at 2:07 AM, <xquery at docbook-autor.de> wrote:

>
>  Hi,
>
> I know that XQuery is typically used for transforming XML into other
> text file formats.
>
> But is it possible to use XQuery for the other way round?
>
> I want to transform a very simple SQL Create Table statement into XML.
>
>
> SQL
> ===
>
> CREATE TABLE mytable1
>
> (
>   FIELD1        xxx;
>   FIELD2        xxx;
>   FIELD3        xxx;
> );
>
> COMMENT ON COLUMN mytable1.FIELD1 'Description1';
> COMMENT ON COLUMN mytable1.FIELD2 'Description2';
>
> CREATE TABLE mytable2
>
> (
>   FIELD1        xxx;
>   FIELD2        xxx;
>   FIELD3        xxx;
> );
>
> COMMENT ON COLUMN mytable2.FIELD1 'Description1';
> COMMENT ON COLUMN mytable2.FIELD3 'Description3';
>
>
> XML
> ===
>
> <table>
>   <title>mytable1</title>
>   <column>
>     <name>FIELD1</name>
>     <comment>Description1</comment>
>   </column>
>   <column>
>     <name>FIELD2</name>
>     <comment>Description2</comment>
>   </column>
>   <column>
>     <name>FIELD1</name>
>     <comment></comment>
>   </column>
> </table>
>
> <table>
>   <title>mytable2</title>
>   <column>
>     <name>FIELD1</name>
>     <comment>Description1</comment>
>   </column>
>   <column>
>     <name>FIELD2</name>
>     <comment></comment>
>   </column>
>   <column>
>     <name>FIELD1</name>
>     <comment>Description3</comment>
>   </column>
> </table>
>
> Can this be done via XQuery? If not which tool could possibly fit my needs?
>
> Best regards
> Michael
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170810/36624e38/attachment.html>

From mike at saxonica.com  Thu Aug 10 00:24:10 2017
From: mike at saxonica.com (Michael Kay)
Date: Thu, 10 Aug 2017 08:24:10 +0100
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
Message-ID: <0282AC98-54ED-4A85-855C-3D78382D9C7C@saxonica.com>

XQuery has no built-in capability to parse SQL or to execute the result after parsing.

You could generate an XQuery parser for a subset of SQL using REx (http://www.bottlecaps.de/rex/), which would give you an XML representation of the SQL command, and you could then write an XSLT or XQuery program that transforms this into your desired output.

Michael Kay
Saxonica

> On 10 Aug 2017, at 07:07, xquery at docbook-autor.de wrote:
> 
> 
> Hi,
> 
> I know that XQuery is typically used for transforming XML into other
> text file formats.
> 
> But is it possible to use XQuery for the other way round?
> 
> I want to transform a very simple SQL Create Table statement into XML.
> 
> 
> SQL
> ===
> 
> CREATE TABLE mytable1
> 
> (
>  FIELD1	xxx;
>  FIELD2	xxx;
>  FIELD3	xxx;
> );
> 
> COMMENT ON COLUMN mytable1.FIELD1 'Description1';
> COMMENT ON COLUMN mytable1.FIELD2 'Description2';
> 
> CREATE TABLE mytable2
> 
> (
>  FIELD1	xxx;
>  FIELD2	xxx;
>  FIELD3	xxx;
> );
> 
> COMMENT ON COLUMN mytable2.FIELD1 'Description1';
> COMMENT ON COLUMN mytable2.FIELD3 'Description3';
> 
> 
> XML
> ===
> 
> <table>
>  <title>mytable1</title>
>  <column>
>    <name>FIELD1</name>
>    <comment>Description1</comment>
>  </column>
>  <column>
>    <name>FIELD2</name>
>    <comment>Description2</comment>
>  </column>
>  <column>
>    <name>FIELD1</name>
>    <comment></comment>
>  </column>
> </table>
> 
> <table>
>  <title>mytable2</title>
>  <column>
>    <name>FIELD1</name>
>    <comment>Description1</comment>
>  </column>
>  <column>
>    <name>FIELD2</name>
>    <comment></comment>
>  </column>
>  <column>
>    <name>FIELD1</name>
>    <comment>Description3</comment>
>  </column>
> </table>
> 
> Can this be done via XQuery? If not which tool could possibly fit my needs?
> 
> Best regards
> Michael
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From gfourny at inf.ethz.ch  Thu Aug 10 00:50:52 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Thu, 10 Aug 2017 07:50:52 +0000
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <0282AC98-54ED-4A85-855C-3D78382D9C7C@saxonica.com>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
	<0282AC98-54ED-4A85-855C-3D78382D9C7C@saxonica.com>
Message-ID: <0FF33261-1A54-4102-8F9C-623A2CAEF6E9@inf.ethz.ch>

Hi Michael,

I agree with Mike, but would add that with XQuery's FLWOR expressions, window clauses, builtin functions (tokenize, replace, match, etc) as well as EXPath modules, you can achieve a lot on text input that is "not too unstructured". I did it quite a few times. Some engines also have builtin modules to parse CSV and others.

Of course, parsing a full language like SQL is best done using the typical approaches (lexer, grammar, etc) as Mike suggests, and is not trivial. But if the subset is really very simple (as simple as your example), known in advance, and if there are no irregularities in newlines, etc, then the above, more ad-hoc approach could work as well quite straightforwardly: a for to iterate on the lines, start tumbling windows at rows that start with "CREATE TABLE", then sub-windows to catch the parentheses and the COMMENTs, and then convert the contents to XML nodes.

If it gets more complex, though, for example if the commands spread differently over lines, or if you cannot have any guarantees on the input (i.e., all you know is that it will be SQL), then generating a parser with a library will definitely be a very much worthier investment.

You would probably walk for a 500-yard trip, and you would probably take a plane, arriving 2 hours in advance at the airport, for a 1000-mile trip. It all depends on what you want to achieve.

I hope this helps.

Kind regards,
Ghislain


> On 10 Aug 2017, at 09:24, Michael Kay <mike at saxonica.com> wrote:
> 
> XQuery has no built-in capability to parse SQL or to execute the result after parsing.
> 
> You could generate an XQuery parser for a subset of SQL using REx (http://www.bottlecaps.de/rex/), which would give you an XML representation of the SQL command, and you could then write an XSLT or XQuery program that transforms this into your desired output.
> 
> Michael Kay
> Saxonica
> 
>> On 10 Aug 2017, at 07:07, xquery at docbook-autor.de wrote:
>> 
>> 
>> Hi,
>> 
>> I know that XQuery is typically used for transforming XML into other
>> text file formats.
>> 
>> But is it possible to use XQuery for the other way round?
>> 
>> I want to transform a very simple SQL Create Table statement into XML.
>> 
>> 
>> SQL
>> ===
>> 
>> CREATE TABLE mytable1
>> 
>> (
>> FIELD1	xxx;
>> FIELD2	xxx;
>> FIELD3	xxx;
>> );
>> 
>> COMMENT ON COLUMN mytable1.FIELD1 'Description1';
>> COMMENT ON COLUMN mytable1.FIELD2 'Description2';
>> 
>> CREATE TABLE mytable2
>> 
>> (
>> FIELD1	xxx;
>> FIELD2	xxx;
>> FIELD3	xxx;
>> );
>> 
>> COMMENT ON COLUMN mytable2.FIELD1 'Description1';
>> COMMENT ON COLUMN mytable2.FIELD3 'Description3';
>> 
>> 
>> XML
>> ===
>> 
>> <table>
>> <title>mytable1</title>
>> <column>
>>   <name>FIELD1</name>
>>   <comment>Description1</comment>
>> </column>
>> <column>
>>   <name>FIELD2</name>
>>   <comment>Description2</comment>
>> </column>
>> <column>
>>   <name>FIELD1</name>
>>   <comment></comment>
>> </column>
>> </table>
>> 
>> <table>
>> <title>mytable2</title>
>> <column>
>>   <name>FIELD1</name>
>>   <comment>Description1</comment>
>> </column>
>> <column>
>>   <name>FIELD2</name>
>>   <comment></comment>
>> </column>
>> <column>
>>   <name>FIELD1</name>
>>   <comment>Description3</comment>
>> </column>
>> </table>
>> 
>> Can this be done via XQuery? If not which tool could possibly fit my needs?
>> 
>> Best regards
>> Michael
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
> 
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From christian.gruen at gmail.com  Thu Aug 10 01:12:10 2017
From: christian.gruen at gmail.com (=?UTF-8?Q?Christian_Gr=C3=BCn?=)
Date: Thu, 10 Aug 2017 10:12:10 +0200
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
Message-ID: <CAP94bnPSYUYqwVqm34tHmXSs73wOnndn0oNrvkzbgEB9OADo7g@mail.gmail.com>

Hi Michael (Sahm),

maybe you?ll need to additionally give us more information on your requirements:

> I want to transform a very simple SQL Create Table statement into XML.

Would you like to parse your SQL (or just DDL) expressions in XQuery
and execute them in a second step? Do you want to store SQL data in an
XML database in a leter step, or do you only want to create a schema
representation of your SQL table definitions in XML, resulting from
your SQL statements?

> Can this be done via XQuery?

The answer is definitely yes. On a logical level, you can do pretty
much everything in XQuery, but I assume your use case is much more
practical?

Best,
Christian


From xquery at docbook-autor.de  Thu Aug 10 01:22:26 2017
From: xquery at docbook-autor.de (xquery at docbook-autor.de)
Date: Thu, 10 Aug 2017 10:22:26 +0200
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <0FF33261-1A54-4102-8F9C-623A2CAEF6E9@inf.ethz.ch>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
	<0282AC98-54ED-4A85-855C-3D78382D9C7C@saxonica.com>
	<0FF33261-1A54-4102-8F9C-623A2CAEF6E9@inf.ethz.ch>
Message-ID: <d148ec3e-4b95-b2a4-994e-15888099bcaa@docbook-autor.de>


 Hi Mike and Ghislain,

> Of course, parsing a full language like SQL is best done using the typical approaches (lexer, grammar, etc) as Mike suggests, and is not trivial. But if the subset is really very simple (as simple as your example), known in advance, and if there are no irregularities in newlines, etc, then the above, more ad-hoc approach could work as well quite straightforwardly: a for to iterate on the lines, start tumbling windows at rows that start with "CREATE TABLE", then sub-windows to catch the parentheses and the COMMENTs, and then convert the contents to XML nodes.


yes, the scenario is really that simple.

I get files with round about 40 to 100 CREATE TABLEs each and have to
transform those into XML files (subsequently I have to transform those
XML files into DocBook entity files where XQuery would come into play
anyway).

I tried to import those CREATE TABLEs into MySQL and to export the
resulting database as XML. Unfortunately MySQL only exports to <table
name="mytable1"> tag level with the CREATE TABLE state as value:

<pma:table name="mytable1">
  CREATE TABLE `mytable1` (
    `FIELD1` xxx DEFAULT NULL,
    `FIELD2` xxx DEFAULT NULL,
    `FIELD3` xxx DEFAULT NULL
    )
</pma:table>

Maybe I'm missing something with the XML export feature of MySQL.

I'm not an XQuery expert... maybe that export will do already to use
XQuery for generating the DocBook entity file.

Is it possible to take apart tag values with XQuery so that every
'FIELDx' gets its own entry after the transformation?

@Ihe Onwuka: Using DB2 is not an option. I just get those files. Best i
can do is to use MySQL.

Best regards
Michael

From xquery at docbook-autor.de  Thu Aug 10 01:36:35 2017
From: xquery at docbook-autor.de (xquery at docbook-autor.de)
Date: Thu, 10 Aug 2017 10:36:35 +0200
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <CAP94bnPSYUYqwVqm34tHmXSs73wOnndn0oNrvkzbgEB9OADo7g@mail.gmail.com>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
	<CAP94bnPSYUYqwVqm34tHmXSs73wOnndn0oNrvkzbgEB9OADo7g@mail.gmail.com>
Message-ID: <6fbbfafd-a5c7-2dcb-0e32-a4bc16d58820@docbook-autor.de>


 Hi Christian,

> Would you like to parse your SQL (or just DDL) expressions in XQuery
> and execute them in a second step? Do you want to store SQL data in an
> XML database in a leter step, or do you only want to create a schema
> representation of your SQL table definitions in XML, resulting from
> your SQL statements?

yes, a "simple" SQL parsing should do.

> The answer is definitely yes. On a logical level, you can do pretty
> much everything in XQuery, but I assume your use case is much more
> practical?

yes, it is. As I mentioned in my previous response I have to transform
lots of files with 40 to 100 CREATE TABLEs each into DocBook entity files.

Done by hand it's extremely unsatisfying... especially because I'm
dealing with transformation of text into text and not some stream or
crypto data.

The plan is that first of all I will generate a DocBook documentation
out of the SQL data. The next step will be that my customer can fill his
database with all the still missing comments of his database columns out
of the then completed entity file (XML to SQL transformation).

Soweit der Plan... ;-)

Best regards from Aachen
Michael

From gfourny at inf.ethz.ch  Thu Aug 10 02:15:11 2017
From: gfourny at inf.ethz.ch (Ghislain  Fourny)
Date: Thu, 10 Aug 2017 09:15:11 +0000
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <6fbbfafd-a5c7-2dcb-0e32-a4bc16d58820@docbook-autor.de>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
	<CAP94bnPSYUYqwVqm34tHmXSs73wOnndn0oNrvkzbgEB9OADo7g@mail.gmail.com>
	<6fbbfafd-a5c7-2dcb-0e32-a4bc16d58820@docbook-autor.de>
Message-ID: <2715C2C0-B7B2-4D5E-9ACC-3AE5D1A82653@inf.ethz.ch>

Dear Michael,

I got the query below to work on the sample that you gave us. It gives the required input with Zorba and requires XQuery 3.0 (for the windows). It only took a few minutes to write and can probably be improved, but this should give you a starting point.

A word of caution: it should work on a bigger input (with more tables) _under the condition that the patterns in the input SQL stay strictly identical_ (same arrangements of comments on the lines, same whitespaces, spaces and tabs, no other commands than those, and so on. In short: no surprises).

In general, if things do not work and you start spending a lot of time debugging and adapting the transformation each time a new input is tried, this is a sign that a lexer and parser, as Mike suggested, may be a better solution, and that this ad-hoc solution is too ad-hoc for the use case at hand.

I hope it helps.

Kind regards,
Ghislain

______
<database>
{
  let $query := "" (: Put the query here -- I put it into a trivial XML file that I opened with doc()/a :)
  for tumbling window $table in tokenize($query, '\n')
  start $line when starts-with($line, "CREATE TABLE")
  end next $next when starts-with($next, "CREATE TABLE")
  let $title := replace($table[1], "CREATE TABLE ", "")

let $columns :=
    for tumbling window $fields in $table
    start previous $p when starts-with($p, "(")
    end next $n when starts-with($n, ");")
    for $field in $fields
    return <name>{replace($field, " ([A-Za-z0-9]+)\txxx;", "$1")}</name>

let $comments :=
    for tumbling window $fields in $table
    start $s when starts-with($s, "COMMENT")
    end $e when starts-with($e, "COMMENT")
    for $field in $fields
    let $comments := replace($field, "COMMENT ON COLUMN " || $title || "\.([A-Za-z0-9]+) '([A-Za-z0-9]+)';" , "$1 $2")
    return <comment field="{tokenize($comments, ' ')[1]}">{tokenize($comments, " ")[2]}</comment>

return
  <table>
    <title>{$title}</title>
    {
      for $c in $columns
      return <column>
        {
          $c,
          <comment>{$comments[@field eq $c]/string()}</comment>
        }
      </column>
    }
  </table>
}
</database>
______

> On 10 Aug 2017, at 10:36, xquery at docbook-autor.de wrote:
> 
> 
> Hi Christian,
> 
>> Would you like to parse your SQL (or just DDL) expressions in XQuery
>> and execute them in a second step? Do you want to store SQL data in an
>> XML database in a leter step, or do you only want to create a schema
>> representation of your SQL table definitions in XML, resulting from
>> your SQL statements?
> 
> yes, a "simple" SQL parsing should do.
> 
>> The answer is definitely yes. On a logical level, you can do pretty
>> much everything in XQuery, but I assume your use case is much more
>> practical?
> 
> yes, it is. As I mentioned in my previous response I have to transform
> lots of files with 40 to 100 CREATE TABLEs each into DocBook entity files.
> 
> Done by hand it's extremely unsatisfying... especially because I'm
> dealing with transformation of text into text and not some stream or
> crypto data.
> 
> The plan is that first of all I will generate a DocBook documentation
> out of the SQL data. The next step will be that my customer can fill his
> database with all the still missing comments of his database columns out
> of the then completed entity file (XML to SQL transformation).
> 
> Soweit der Plan... ;-)
> 
> Best regards from Aachen
> Michael
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



From ihe.onwuka at gmail.com  Thu Aug 10 03:17:55 2017
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Thu, 10 Aug 2017 06:17:55 -0400
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <CALfs7+xCNNvoffEyLz9fhdQJqQc8EQ99SY__4rJ6=QOyYgSHqg@mail.gmail.com>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
	<CALfs7+xCNNvoffEyLz9fhdQJqQc8EQ99SY__4rJ6=QOyYgSHqg@mail.gmail.com>
Message-ID: <CALfs7+zgi+gHisxAJieSfKa0vo44VH8=S4Kr6Lm=dUvXphsP3Q@mail.gmail.com>

Here.

https://www.ibm.com/developerworks/data/library/techarticle/dm-1006queriespurexml/index.html

On Thu, Aug 10, 2017 at 2:13 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:

> DB2 version 10 onwards lets you mix SQL and XQuery commands in one query.
>
> On Thu, Aug 10, 2017 at 2:07 AM, <xquery at docbook-autor.de> wrote:
>
>>
>>  Hi,
>>
>> I know that XQuery is typically used for transforming XML into other
>> text file formats.
>>
>> But is it possible to use XQuery for the other way round?
>>
>> I want to transform a very simple SQL Create Table statement into XML.
>>
>>
>> SQL
>> ===
>>
>> CREATE TABLE mytable1
>>
>> (
>>   FIELD1        xxx;
>>   FIELD2        xxx;
>>   FIELD3        xxx;
>> );
>>
>> COMMENT ON COLUMN mytable1.FIELD1 'Description1';
>> COMMENT ON COLUMN mytable1.FIELD2 'Description2';
>>
>> CREATE TABLE mytable2
>>
>> (
>>   FIELD1        xxx;
>>   FIELD2        xxx;
>>   FIELD3        xxx;
>> );
>>
>> COMMENT ON COLUMN mytable2.FIELD1 'Description1';
>> COMMENT ON COLUMN mytable2.FIELD3 'Description3';
>>
>>
>> XML
>> ===
>>
>> <table>
>>   <title>mytable1</title>
>>   <column>
>>     <name>FIELD1</name>
>>     <comment>Description1</comment>
>>   </column>
>>   <column>
>>     <name>FIELD2</name>
>>     <comment>Description2</comment>
>>   </column>
>>   <column>
>>     <name>FIELD1</name>
>>     <comment></comment>
>>   </column>
>> </table>
>>
>> <table>
>>   <title>mytable2</title>
>>   <column>
>>     <name>FIELD1</name>
>>     <comment>Description1</comment>
>>   </column>
>>   <column>
>>     <name>FIELD2</name>
>>     <comment></comment>
>>   </column>
>>   <column>
>>     <name>FIELD1</name>
>>     <comment>Description3</comment>
>>   </column>
>> </table>
>>
>> Can this be done via XQuery? If not which tool could possibly fit my
>> needs?
>>
>> Best regards
>> Michael
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20170810/50dc5475/attachment.html>

From xquery at docbook-autor.de  Fri Aug 11 01:15:10 2017
From: xquery at docbook-autor.de (xquery at docbook-autor.de)
Date: Fri, 11 Aug 2017 10:15:10 +0200
Subject: [xquery-talk] SQL to XML with XQuery?
In-Reply-To: <2715C2C0-B7B2-4D5E-9ACC-3AE5D1A82653@inf.ethz.ch>
References: <49a93dcf-e0ab-fbea-af96-be283bc2ac3d@docbook-autor.de>
	<CAP94bnPSYUYqwVqm34tHmXSs73wOnndn0oNrvkzbgEB9OADo7g@mail.gmail.com>
	<6fbbfafd-a5c7-2dcb-0e32-a4bc16d58820@docbook-autor.de>
	<2715C2C0-B7B2-4D5E-9ACC-3AE5D1A82653@inf.ethz.ch>
Message-ID: <797fbbd6-b3cc-b9a8-aa35-1d9a70ebfba5@docbook-autor.de>


 Hi Ghislain,

> I got the query below to work on the sample that you gave us. It gives the required input with Zorba and requires XQuery 3.0 (for the windows). It only took a few minutes to write and can probably be improved, but this should give you a starting point.

thanks a lot! I will test it over the weekend and report the results.

Have a nice weekend and best regards
Michael