From g at 28.io Mon Sep 2 06:03:36 2013 From: g at 28.io (Ghislain Fourny) Date: Mon, 2 Sep 2013 15:03:36 +0200 Subject: [xquery-talk] operations on derived numeric type In-Reply-To: <5220E21A.7000301@benibela.de> References: <52207DE5.3010709@benibela.de> <5220E21A.7000301@benibela.de> Message-ID: Hi, A while ago, I also thought of the expression "an atomic value of type X" to imply that the value is annotated with that type X, i.e., that the value has "the" dynamic type X. As Mike says though, in the specification, it only really means that the value matches type X (according to the sequence/item type matching semantics). After several discussions around types in XQuery, I now tend to visualize dynamic types as blackboxes with a "does it match" API: you cannot look inside an atomic value and ask for "the" dynamic type, but you can ask "does this sequence sequence-type-match that sequence type?". Does it make sense? Kind regards, Ghislain On Aug 30, 2013, at 8:19 PM, Benito van der Zander wrote: > Hi, >> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128). > > So in any case the spec says it returns a value of type x, it can also return a type derived from x. > > And xs:byte(1) + xs:byte(1) instance of xs:byte might also be true. > > I would have expected it to say that explicitly, like "which always returns an xs:integer or derived type derived from it" instead just "which always returns an xs:integer." . > >> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation). > > That sounds kind of confusing > > > Benito > > On 08/30/2013 03:24 PM, Michael Kay wrote: >> On 30 Aug 2013, at 12:11, Benito van der Zander wrote: >> >> >>> Hi, >>> is it true that *all* operations on types derived from the numeric types return a value of one of the four base numeric types? >>> For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)). >>> >> Certainly for all arithmetic operations, yes. (Obviously not for operations like (a gt b). >> >>> What's the point of even having these sub types then? >>> >> In my view there's very little point in having these subtypes, but they are there in XSD so XQuery supports them. >> >>> And why does the XQuery 1 test suite have two different output files for the "abs(xs:byte(0)) instance of xs:byte" case (K2-ABSFunc-46)? >>> One is "true", the other is "false" >>> >> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128). >> >> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation). >> >> Michael Kay >> Saxonica >> _______________________________________________ >> >> 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 Mon Sep 2 06:29:43 2013 From: mike at saxonica.com (Michael Kay) Date: Mon, 2 Sep 2013 14:29:43 +0100 Subject: [xquery-talk] operations on derived numeric type In-Reply-To: <52248164.7090303@benibela.de> References: <52207DE5.3010709@benibela.de> <5220E21A.7000301@benibela.de> <52248164.7090303@benibela.de> Message-ID: On 2 Sep 2013, at 13:15, Benito van der Zander wrote: > > > So taking this further: > > Even xs:decimal(4.0) instance of xs:int, might be true, since the int is still a decimal. > I have certainly argued for that interpretation on occasions, though I found that for practical reasons it's best for casts and constructors to always return the specific type requested. (Otherwise people with "instance of" or "typeswitch" constructions that take an unexpected branch get upset.) Michael Kay Saxonica From benito at benibela.de Tue Sep 3 04:11:16 2013 From: benito at benibela.de (Benito van der Zander) Date: Tue, 03 Sep 2013 13:11:16 +0200 Subject: [xquery-talk] operations on derived numeric type In-Reply-To: References: <52207DE5.3010709@benibela.de> <5220E21A.7000301@benibela.de> Message-ID: <5225C3D4.7020802@benibela.de> Hi, > now tend to visualize dynamic types as blackboxes with a "does it match" API: you cannot look inside an atomic value and ask for "the" dynamic type, but you can ask "does this sequence sequence-type-match that sequence type?". Although you can get the actual type with a long typeswitch statement, if no additional schemas are loaded. Just for fun I now changed the arithmetic functions to auto cast integers of any decimal type to xs:integer and ran the old XQTS on it. This causes quite a few tests to fail (e.g. op-numeric-add-1) Benito On 09/02/2013 03:03 PM, Ghislain Fourny wrote: > Hi, > > A while ago, I also thought of the expression "an atomic value of type X" to imply that the value is annotated with that type X, i.e., that the value has "the" dynamic type X. As Mike says though, in the specification, it only really means that the value matches type X (according to the sequence/item type matching semantics). > > After several discussions around types in XQuery, I now tend to visualize dynamic types as blackboxes with a "does it match" API: you cannot look inside an atomic value and ask for "the" dynamic type, but you can ask "does this sequence sequence-type-match that sequence type?". > > Does it make sense? > > Kind regards, > Ghislain > > > On Aug 30, 2013, at 8:19 PM, Benito van der Zander wrote: > >> Hi, >>> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128). >> So in any case the spec says it returns a value of type x, it can also return a type derived from x. >> >> And xs:byte(1) + xs:byte(1) instance of xs:byte might also be true. >> >> I would have expected it to say that explicitly, like "which always returns an xs:integer or derived type derived from it" instead just "which always returns an xs:integer." . >> >>> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation). >> That sounds kind of confusing >> >> >> Benito >> >> On 08/30/2013 03:24 PM, Michael Kay wrote: >>> On 30 Aug 2013, at 12:11, Benito van der Zander wrote: >>> >>> >>>> Hi, >>>> is it true that *all* operations on types derived from the numeric types return a value of one of the four base numeric types? >>>> For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)). >>>> >>> Certainly for all arithmetic operations, yes. (Obviously not for operations like (a gt b). >>> >>>> What's the point of even having these sub types then? >>>> >>> In my view there's very little point in having these subtypes, but they are there in XSD so XQuery supports them. >>> >>>> And why does the XQuery 1 test suite have two different output files for the "abs(xs:byte(0)) instance of xs:byte" case (K2-ABSFunc-46)? >>>> One is "true", the other is "false" >>>> >>> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128). >>> >>> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation). >>> >>> Michael Kay >>> Saxonica >>> _______________________________________________ >>> >>> 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 g at 28.io Tue Sep 3 05:28:52 2013 From: g at 28.io (Ghislain Fourny) Date: Tue, 3 Sep 2013 14:28:52 +0200 Subject: [xquery-talk] operations on derived numeric type In-Reply-To: <5225C3D4.7020802@benibela.de> References: <52207DE5.3010709@benibela.de> <5220E21A.7000301@benibela.de> <5225C3D4.7020802@benibela.de> Message-ID: <5D431032-842E-450F-BA96-3CCC074F3413@28.io> Hi Benito, It makes sense -- it looks like these tests might make stronger assumptions than the spec does. It would be great if you could file a bug against the test suite (https://www.w3.org/Bugs/Public/, under XPath / XQuery / XSLT) with a list of the involved test case names so it does not get forgotten. I think we may need to have a discussion on that. Many thanks and kind regards, Ghislain On Sep 3, 2013, at 1:11 PM, Benito van der Zander wrote: > Hi, >> now tend to visualize dynamic types as blackboxes with a "does it match" API: you cannot look inside an atomic value and ask for "the" dynamic type, but you can ask "does this sequence sequence-type-match that sequence type?". > > Although you can get the actual type with a long typeswitch statement, if no additional schemas are loaded. > > Just for fun I now changed the arithmetic functions to auto cast integers of any decimal type to xs:integer and ran the old XQTS on it. > This causes quite a few tests to fail (e.g. op-numeric-add-1) > > Benito > > On 09/02/2013 03:03 PM, Ghislain Fourny wrote: >> Hi, >> >> A while ago, I also thought of the expression "an atomic value of type X" to imply that the value is annotated with that type X, i.e., that the value has "the" dynamic type X. As Mike says though, in the specification, it only really means that the value matches type X (according to the sequence/item type matching semantics). >> >> After several discussions around types in XQuery, I now tend to visualize dynamic types as blackboxes with a "does it match" API: you cannot look inside an atomic value and ask for "the" dynamic type, but you can ask "does this sequence sequence-type-match that sequence type?". >> >> Does it make sense? >> >> Kind regards, >> Ghislain >> >> >> On Aug 30, 2013, at 8:19 PM, Benito van der Zander wrote: >> >>> Hi, >>>> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128). >>> So in any case the spec says it returns a value of type x, it can also return a type derived from x. >>> >>> And xs:byte(1) + xs:byte(1) instance of xs:byte might also be true. >>> >>> I would have expected it to say that explicitly, like "which always returns an xs:integer or derived type derived from it" instead just "which always returns an xs:integer." . >>> >>>> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation). >>> That sounds kind of confusing >>> >>> >>> Benito >>> >>> On 08/30/2013 03:24 PM, Michael Kay wrote: >>>> On 30 Aug 2013, at 12:11, Benito van der Zander wrote: >>>> >>>> >>>>> Hi, >>>>> is it true that *all* operations on types derived from the numeric types return a value of one of the four base numeric types? >>>>> For example xs:byte(1) + xs:byte(1) or abs(xs:byte(1)). >>>>> >>>> Certainly for all arithmetic operations, yes. (Obviously not for operations like (a gt b). >>>> >>>>> What's the point of even having these sub types then? >>>>> >>>> In my view there's very little point in having these subtypes, but they are there in XSD so XQuery supports them. >>>> >>>>> And why does the XQuery 1 test suite have two different output files for the "abs(xs:byte(0)) instance of xs:byte" case (K2-ABSFunc-46)? >>>>> One is "true", the other is "false" >>>>> >>>> The specification says that abs() applied to an xs:byte value returns an xs:integer. An implementation that returns an xs:byte conforms to that rule, because every xs:byte is an xs:integer. So some implementations might return an xs:integer that is an xs:byte, others might return an xs:integer that is not an xs:byte. Note that there is one case where the result cannot be an xs:byte, namely where the input is xs:byte(-128). >>>> >>>> (I suspect that Saxon returns the original value unchanged, including type annotation, if it is positive, and returns a value with type annotation xs:integer if it is negative. That's a permitted and in my view reasonable implementation). >>>> >>>> Michael Kay >>>> Saxonica >>>> _______________________________________________ >>>> >>>> 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 g at 28.io Wed Sep 25 01:14:47 2013 From: g at 28.io (Ghislain Fourny) Date: Wed, 25 Sep 2013 10:14:47 +0200 Subject: [xquery-talk] Element list to comma seperated list In-Reply-To: <1380044176.73927.YahooMailNeo@web141603.mail.bf1.yahoo.com> References: <1380044176.73927.YahooMailNeo@web141603.mail.bf1.yahoo.com> Message-ID: Hi, fn:string-join is a W3C-standardized function, not a FunctX function. Are you sure your XQuery processor does not support it? http://www.w3.org/TR/xpath-functions/#func-string-join http://www.w3.org/TR/xpath-functions-30/#func-string-join Kind regards, Ghislain On Sep 24, 2013, at 7:36 PM, sudheshna iyer wrote: > Hello All, > > How do I convert the element list into comma separated list in xquery. I don't have functionx functions. So I can't use string-join. > > eg: > > > > pos1 > pos2 > > > > > Output: > > > pos1,pos2 > > > _______________________________________________ > talk at x-query.com > http://x-query.com/mailman/listinfo/talk From g at 28.io Wed Sep 25 01:18:44 2013 From: g at 28.io (Ghislain Fourny) Date: Wed, 25 Sep 2013 10:18:44 +0200 Subject: [xquery-talk] Element list to comma seperated list In-Reply-To: References: <1380044176.73927.YahooMailNeo@web141603.mail.bf1.yahoo.com> Message-ID: <46E13C2C-2933-430D-96E4-6F82B7F0028E@28.io> Hi Josh, Apologies about the redundant answer, my e-mail client somehow did not show me you had already answered. :-) Kind regards, Ghislain On Sep 24, 2013, at 7:58 PM, Josh Spiegel wrote: > > fn:string-join is a standard function: > http://www.w3.org/TR/xpath-functions/#func-string-join > > So you shouldn't need functionx functions. Something like this should work: > > > { > fn:string-join($customer/tns:General/Positions/corecomponents:Position, ",") > } > > > Josh > > On Sep 24, 2013, at 10:36 AM, sudheshna iyer wrote: > >> Hello All, >> >> How do I convert the element list into comma separated list in xquery. I don't have functionx functions. So I can't use string-join. >> >> eg: >> >> >> >> pos1 >> pos2 >> >> >> >> >> Output: >> >> >> pos1,pos2 >> >> >> _______________________________________________ >> 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 geert.josten at dayon.nl Mon Sep 30 00:05:41 2013 From: geert.josten at dayon.nl (Geert Josten) Date: Mon, 30 Sep 2013 09:05:41 +0200 Subject: [xquery-talk] [ANN] XML Amsterdam 2013 registration is open! Message-ID: <801d555358ea0438968dfbed26a0fd98@mail.gmail.com> XML Amsterdam 2013 conference is open for registration! Keynotes by Norm Walsh, and Steven Pemberton. Michael Kay, Eric van der Vlist, William Candillon, and more speaking. And of course a MarkLogic DemoJam! http://www.xmlamsterdam.com/2013/registration BE QUICK, the early bird discount of 50 up to 100 euro expires at 7 October! HIGHLIGHTS ----------------- . 23rd of October 2013, The Bazel City Archive, Amsterdam . One day, two tracks, 15 years of XML as theme . Keynotes by Norm Walsh, and Steven Pemberton . 12 breakouts with a.o. speakers from 28msec, Amis, BBC, EMC, Saxonica, and University of Bielefeld . Guided tour through the beautiful building of The Bazel . Free MarkLogic dinner, and DemoJam PROGRAM --------------- Details of the preliminary program, abstracts, and bios can be found at: http://www.xmlamsterdam.com/2013/program REGISTRATION -------------------- Come and register now, and get 20% Early-Bird discount for yourself, and 40% discount for any colleague you bring along! http://www.xmlamsterdam.com/2013/registration Registration includes free access to the guided tour, and the MarkLogic dinner and demojam. MARKLOGIC DEMOJAM -------------------------------- MarkLogic is sponsoring the entire evening program, including free drinks, dinner, and most importantly the renowned MarkLogic DemoJam. Details about entering the DemoJam can be found at http://www.xmlamsterdam.com/2013/demojam -------- Feel free to contact us with any question or idea regarding the conference at info at xmlamsterdam.com! Kind regards, Geert Josten, Dayon BV On behalf of: XML Amsterdam 2013 info at xmlamsterdam.com http://www.xmlamsterdam.com http://twitter.com/xmlamsterdam