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>http://www.w3.org/2007/rif-builtin-function#)
for the functions instead of using the defined namespace
(<http://www.w3.org/2005/xpath-functions>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>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. =
========================================================================