- From: Axel Polleres <axel.polleres@deri.org>
- Date: Wed, 13 May 2009 02:55:39 +0100
- To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
I resolved the respective Editor's notes in DTB according to Michael Kay's answer. For us this means that: - for func:years-from-duration (and similar for other functions) we only take yearMonthDuration as the domain. - for func:divide-yearMonthDuration (and similar for other functions) we take as the domain the union of all numeric types instead of only double. Axel -------- Original Message -------- Subject: Re: Clarification request on XPath/XQuery functions and operators regarding implicit casts Date: Wed, 13 May 2009 00:35:17 +0100 From: Axel Polleres <axel.polleres@deri.org> Organization: DERI, National University of Ireland, Galway To: Michael Kay <mike@saxonica.com> CC: public-qt-comments@w3.org, 'RIF WG Chairs' <team-rif-chairs@w3.org> References: <4A09FCAB.30903@deri.org> <593A988C946045409B511B8991A8B57E@Sealion> Thanks a lot for the quick and helpful reply! Axel Michael Kay wrote: >> I would kindly ask for advice on the following questions >> regarding implicit casts and type promotions in XPath/XQuery functions >> >> >> 1) For instance, fn:year-from-dateTime >> (http://www.w3.org/TR/xpath-functions/#func-year-from-dateTime) >> does not mention any implicit casts in its definition. >> Does that imply a type error if I call >> >> fn:year-from-dateTime(s) >> >> with an xs:string value s as parameter, even if s is in the lexical >> space of xs:dateTime or is a cast here implicit? > > The only implicit conversions on a function call are those described at > > http://www.w3.org/TR/xpath20/#id-function-calls > > that is, > > * atomization of nodes > > * conversion of untypedAtomic values to the required type (by casting) > > * (and in other functions) promotion of numeric values, for example integer > to double. > > There is no implicit casting from xs:string. >> On the other hand, fn:years-from-duration >> (http://www.w3.org/TR/xpath-functions/#func-year-from-dateTime) >> mentions explicitly casting in its definition: >> >> "The result is obtained by casting $arg to an >> xs:yearMonthDuration (see >> 17.1.4 Casting to duration types) and then computing the >> years component >> as described in 10.3.1.3 Canonical representation." >> >> Would that imply that fn:years-from-duration(s) >> would accept an xs:string s castable to xs:yearMonthDuration >> as argument? > > No, this casting is internal to the function, the supplied value must still > conform to the rules given in the function signature, which require the > value to be an instance of xs:duration (after atomization and conversion of > untypedAtomic). >> In this case is this different treatment of the extraction functions >> for years from dateTime and duration intended? >> >> 2) Similarly, >> op:divide-yearMonthDuration >> (http://www.w3.org/TR/xpath-functions/#func-divide-yearMonthDuration) >> accepts as second argument xs:double. >> >> Again the question is whether casting here is implicit, as e.g. the >> example suggests: >> >> op:divide-yearMonthDuration(xs:yearMonthDuration("P2Y11M"), 1.5) >> >> where 1.5 is a decimal value, isn't it? > > The standard function calling rules allow numeric promotion: if the required > type is xs:double, the supplied value can be xs:integer, xs:decimal, or > xs:double. >> >> In general, I would like to find where in the spec I would >> find hints on >> whether conversions in functions and operators are meant to >> be implicit >> or not, and, if they are, then why in some cases, e.g. >> fn:years-from-duration >> casting is mentioned explicitly? >> > > Section 3.1.5 of the XPath language spec. > > Best regards, > > Michael Kay > Saxonica > -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/ -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/
Received on Wednesday, 13 May 2009 01:56:20 UTC