Re: Jim Melton: XML Query WG review of RIF Datatypes and Built-Ins 1.0

Hi Sandro, all,

Thanks for the excellent comments. I won't be able to work on these
however at least not within the next month and would appreciate
if one of the other editors could take over.

Thanks,
Axel

On 25 Sep 2009, at 02:05, Sandro Hawke wrote:

>
> Here's the review of RIF from the XML Query WG, forwarded with  
> permission.
>
>
>
> From: "Jim Melton" <jim.melton@oracle.com>
> Date: 24 September 2009 23:43:13 GMT+01:00
> To: <sandro@w3.org>
> Cc: <sca@us.ibm.com>, <addison@amazon.com>, <liam@w3.org>, <ishida@w3.org 
> >, <plh@w3.org>, <ivan@w3.org>, <team-rif-chairs@w3.org>, <chairs@w3.org 
> >
> Subject: XML Query WG review of RIF Datatypes and Built-Ins 1.0
>
>
> Sandro,
>
> The XML Query WG has completed its review of
> RIF Datatypes and
> Built-Ins 1.0 and has developed some comments.  Please note that
> Sharon and I initially agreed to submit the XML Query WG's comments  
> and
> the XSL WG's comments jointly, but my WG objected on the grounds that
> they had not yet seen the XSL WG's comments and did not want to wait  
> for
> them.  Consequently, Sharon will submit the XSL WG's comments
> separately whenever they are ready.
>
>
> <comments>
>
> 1) Thanks for giving us the opportunity to review this
> document.  We were very pleased to see that you have based much of
> this spec on the Functions and Operators specification that we  
> developed,
> as well as on the XML Schema Part 2 Datatypes spec on which we also
> depend.  There are other W3C WGs whose documents made use of the
> F&O functions, but redefined the functions instead of incorporating
> them by reference.  Your approach is manifestly appropriate.
> Thanks!
>
> 2) We are slightly concerned by the fact that you state in the  
> Overview
> that "A large part of the definitions of the listed functions and
> operators are adopted from [XPath-Functions]," but that you define a
> different namespace
> (
>
> http://www.w3.org/2007/rif-builtin-function
> #) for the functions
> instead of using the defined namespace
> (
>
> http://www.w3.org/2005/xpath-functions
> ) of those functions that have
> been adopted.  We note that Section 4 uses the word
> "adapted" instead of "adopted", which has
> significantly different connotations.  We have concluded from
> additional text in the document that "adapted" is the word that
> you intended to use and recommend that you resolve the discrepancy by
> correcting the Overview.
>
> 3) In section 2.2.1, we read the statement "since xs:duration does
> not have a well-defined value space."  We believe that
> mischaracterizes the rationale for the creation of the types
> xs:dayTimeDuration and xs:yearMonthDuration.  The rationale is
> actually that the xs:duration data type is not fully ordered, while  
> the
> two types derived from xs:duration are fully ordered.  It is
> unlikely that XML Schema will be able to redefine xs:duration in a way
> that is both compatible and fully ordered.
>
> 4) Also, in section 2.2.1, since xs:dateTimeStamp is taken from XSD  
> 1.1,
> it would also make sense to take xs:dayTimeDuration and
> xs:yearMonthDuration from XSD 1.1, rather than from XDM. The  
> definitions
> are equivalent by design. (This also affects section 2.3.)
>
>
> 5)
> In section 2.3, the type hierarchy for integer subtypes
> appears to be incorrect.  unsignedLong should not be a subtype of
> positiveInteger (because it allows the value zero). Also the prefix
> "xs:" is included or omitted indiscriminately.
>
> 6) In section 4.3, we learn that "Itruth Iexternal( ?arg1;
> pred:is-literal-not-DATATYPE ( ?arg1 ) )(s1) = t if and only if s1  
> is in
> the value space of one of the datatypes in
> <
>
> http://www.w3.org/TR/rif-dtb/#sec-data-types
> >DTS but not in the
> value space of the datatype with shortname DATATYPE, and f
> otherwise."  We believe that means that the predicate
> pred:is-literal-not-integer returns f if the value of its argument  
> is not
> in the value space of any datatype in DTS!  If that is true, then it
> is highly misleading, because returning false implies that the value  
> is a
> literal of type integer.  We recommend that you reconsider this
> definition so that the predicate returns true when the value is either
> (a)not in the value space of any datatype in DTS or (b)is in the value
> space of some data type in DTS but not in the value space of the
> specified datatype.
>
> 7) In section 4.4.1, we discovered the trivial typographical error
> "funcitons".  We also noticed the trivial typographical
> error "ab" (should be "an").
>
> 8) In section 4.5.1, Numeric functions, it is not clear whether  
> functions
> such as func:numeric-add accept arguments of mixed type (e.g. integer
> plus double).  Although neither sections 1.3, 1.4 and 6.2 of
> Functions and Operators nor appendix B of XPath 2.0 are wonderfully  
> clear
> on the point, our reading is that the underlying function
> op:numeric-add() does not accept mixed arguments; rather, when the  
> XPath
> "+" operator is applied to an integer and a double, the integer
> is promoted to a double and the function op:numeric-add(double,  
> double)
> is called. The operator accepts mixed-type arguments, but the  
> underlying
> function does not. (Others may disagree with this reading, as it  
> really
> isn't 100% clear.)
>
> 9) Section 4.7.1.2. Note that for reasons that are entirely
> paternalistic, the fn:concat() function requires two or more  
> arguments.
> Also, the reference to xs:anyAtomicType seems odd: this abstract type
> doesn't seem to be present in RIF.
>
> 10) Section 4.11: We suspect there is a fourth difference between RIF
> Lists and XPath sequences: in RIF, there is no equivalence between an
> atomic value and a singleton list containing that value. (Otherwise,
> pred:is-list() would be meaningless).
>
> 11) Section 4.11.1. Is it wise to number positions in a list starting
> from zero, while numbering characters within a string (for example, in
> the substring() function) from 1?  We think this inconsistency will
> confuse your readers and users.
>
> 12) Section 4.11.4.11: There is no function fn:union. The link is to
> op:union, but the RIF function is essentially unrelated to op:union,  
> as
> it is defined on atomic values rather than nodes. Same applies to
> 4.11.4.13 fn:intersect and 4.11.4.14 fn:except. XPath contains no
> functions to manipulate sequences of atomic values in this way: such
> functions can easily be written by users as explained in F+O appendix
> E.2.
>
> 13) Section 4.11.4.12: it's not clear what "in the same order"
> means. Order of first appearance, perhaps?
>
> 14) In various places in section 4, we read phrases such as "the
> value of the function is unspecified".  The discussion early in
> section 4 of that term states that implementations are free to do as  
> they
> wish, including returning either true or false, as well as aborting
> evaluation of the containing expression/query.  In the specs for
> which we are responsible, as well as some well-known international
> standards, the term "implementation-dependent" is used for the
> same purpose.  You might consider the use of that term instead.
>
> 15) Near the beginning of section 2.3 and in Appendix 6, we see three
> places where an unexpected character (a hollow square box) appears.
>
> </comments>
>
> Hope this helps,
>    Jim
> = 
> = 
> ======================================================================
> Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone:  
> +1.801.942.0144
>   Chair, W3C XML Query WG; XQX (etc.) editor       Fax :  
> +1.801.942.3345
> Oracle Corporation        Oracle Email: jim dot melton at oracle dot  
> com
> 1930 Viscounti Drive      Standards email: jim dot melton at acm dot  
> org
> Sandy, UT 84093-1063 USA          Personal email: jim at melton dot  
> name
> = 
> = 
> ======================================================================
> =  Facts are facts.   But any opinions expressed are the  
> opinions      =
> =  only of myself and may or may not reflect the opinions of  
> anybody   =
> =  else with whom I may or may not have discussed the issues at  
> hand.  =
> = 
> = 
> ======================================================================
>
>
>

-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland,  
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Friday, 25 September 2009 06:25:49 UTC