W3C home > Mailing lists > Public > public-rif-comments@w3.org > September 2009

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

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 30 Sep 2009 00:24:46 -0400
To: "Jim Melton" <jim.melton@oracle.com>
cc: public-rif-comments@w3.org
Message-ID: <19843.1254284686@waldron>

Dear Jim,

Thank you and the XML Query WG for your detailed review [1] of RIF
Datatypes and Builtins.  We appreciate the time you put in, finding
weaknesses and errors in our draft.

Our responses to your comments are inline below.  It would be most
helpful if you could let us know very soon whether you find these
responses satisfactory.  (If you are satisfied, we can go ahead and
publish as Candidate Recommendation immediately.  Best case, we could
publish on Thursday October 1.)

Our wiki has the latest version (including the changes made in
response to your comments):

  http://www.w3.org/2005/rules/wiki/DTB

and a diff of those changes:

  http://www.w3.org/2005/rules/wiki/index.php?title=DTB&diff=11377&oldid=11060

> 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!

We were glad to be able to reuse so much of your work.  (I expect our
users and implementors will be glad, too.  Several implementors have
said they plan to re-use xpath libraries.)

> 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.

We believe "adapted" is the more accurate term here, and have changed
the document to reflect this.  At the end of section 4 (just before
4.1) we added this clarifying sentence:

"The differences from the original [XPath-Functions] include the
handling of errors, the differentiation between predicates and
functions, and a few specific differences noted in the definitions
below."

The different namespace URIs are intended to allow for these changes,
and are also to save users from having to remember which RIF functions
are xpath functions and which are xpath operators (for which RIF would
have to provide a namespace, since xpath does not) or new RIF
functions.  (RIF does not have the function/operator distinction.)

> 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.

It looks like this comment about xs:duration in our draft was based on
the XSD 1.0 defintion.  As you suggest, it may have been fixed in XSD
1.1.  We have decided not to add it, however, since we already agreed
to have the same datatypes as OWL 2, which is already at Proposed
Recommendation.

We have removed the now-incorrect explanation you cite.

> 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.)

We would rather avoid this change, at this point, because it would
increase the risky dependency on XSD 1.1.  The OWL WG was recently
delayed because of such a dependency, and is left with the awkward
work-around you see here:

  http://www.w3.org/TR/2009/PR-owl2-overview-20090922/#sotd-xml-dep

If XSD 1.1 makes it to PR before RIF, we can make this change at that
point.

> 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.

Thanks for catching this; it's fixed now.

> 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.

We believe the definition as given is correct, but that the intended
meaning of negative guards was not clear.  We have added this note to
the end of section 4.3:

"Note: The semantics of negative guards may be surprising. The
is-literal-not-String guard essentially asks, "Is this a literal, and
(if it is) is it something other than a String?" It could also be read
as "Is this a decimal or a float or a double or a date or a dateTime,
etc, [for every datatype except string] ?". The negative guards are
formulated like this to allow for rules which detect, for instance,
some kinds of bad inputs, while still using the open world assumption
of some RIF dialects."

Hopefully, that's detailed enough to show that the definition is
correct.  A more-detailed explanation of why we can't provide
is-not-String seems out-of-scope for this document.

> 7) In section 4.4.1, we discovered the trivial typographical error
> "funcitons".  We also noticed the trivial typographical
> error "ab" (should be "an").

Fixed, thanks.

> 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.)

Thanks for pointing out this omission.  We have added text requiring
types be promoted in RIF, in the Mapping part of section 4.5.1.

> 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.

Okay, we've gone with two-or-more, and removed anyAtomicType.

> 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).

Fixed, thanks.

> 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.

We struggled with this some more today, but decided to leave indexing
as is.  It's a really infortunate situation, and we can't see any way
forward which wont confuse users.  Given that lists are substantially
different from xpath sequences, well, hopefully people will understand
and tolerate this approach.

> 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.

Our sense was that this difference was within the wiggle-room of
"adapted from", but I guess we could change it to "inspired by" or
"contrast with", if you think that's important.  We did want to
highlight the fact that xpath does have something with the same name.

> 13) Section 4.11.4.12: it's not clear what "in the same order"
> means. Order of first appearance, perhaps?

Fixed, thanks.

> 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.

Thanks, I agree with you on this, but the group hasn't had a chance to
talk it through.  I'd like to let addressing this wait until the next
round.

> 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.

There is a community, including some of our editors, who use that box
to signal the end of a formal definition.  Personally, I find it
confusing, and would prefer we use some CSS styling to set off the
definition.  The WG hasn't had a chance to talk about this, and I'd
like to wait until the next round for this, as well.

> </comments>
> 
> Hope this helps,
>    Jim

Indeed, thank you again for catching all this, and please let us know
if our response is satisfactory.

     -- Sandro (on behalf of RIF WG)


[1] http://lists.w3.org/Archives/Public/public-rif-comments/2009Sep/0008
Received on Wednesday, 30 September 2009 04:24:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 September 2009 04:24:49 GMT