Re: [DTB] Datatypes and Built-ins first run to clean up and extend the initial list

herewith some comments on the draft:

- sections 2.1 and 2.2 are part of FLD/BLD, since they are concerned 
with how built-ins are used in the language. They should be removed from 
this document.
- the prefixes rifBuiltinPred, fn, and op  should be explained
- predicates and functions are introduced using a particular syntax, 
which seems to originate from the XQuery document.  The syntax does not 
seem to have much to do with RIF, nor is it explained. I would suggest 
to explain the functions and predicates in a syntax-independent way.
- section 2.3.1 should precisely explain the connection between the 
guard predicates and the datatypes. Additionally, it should also explain 
the guard predicates of datatypes which are not required to be 
implemented by every RIF-compliant implementation, but which are 
nonetheless supported by RIF.
- why is it the case that "RIF does not require guards for all 
datatypes"?  I think it would be entirely reasonable to require 
supporting the corresponding guard if you want to use a data type.
- section 2.3.2: cast functions should be defined explicitly, rather 
than relying on an informal link to external document.
- I believe it is not possible to define cast functions for symbol 
spaces that are not datatypes in a meaningful way
- the predicates and functions in the sections 2.3.2 through 2.3.7 need 
to be defined
- section 2.3.3.1: I do not understand the concern "Also, since built-in 
functions are functions, we have to accept TERMs as inputs, which can be 
variables, constants or any other nested function terms."; I do not 
think the definition of the functions needs to be concerned with the 
syntax.  You only need to define the function, i.e., the output value 
corresponding to each input tuple.
- section 2.3.3.2: at the last face-to-face we resolved how to deal with 
errors: every erroneous tuple does not have a defined truth value; this 
is left to the user.
- section 2.3.4.1: regarding the comment "The original definition of 
fn:concat allows an arbitrary number of arguments: 'Accepts two 
xs:anyAtomicType arguments'. This is not compliant with the definition 
of BLD that each function (builtin or not) has a fixed arity. However, 
srictly speaking any n-ary concat can be expressed by nesting binary 
concats. Also note that this function has implicit casts (as defined in 
the XPath/XQuery functions and operators document).", I think we should 
just define binary concatenations.
- section 2.3.4.1: regarding substring: we should go for the ternary 
variant; the case where length=-1 could be defined to be the same as the 
binary case in Xquery. similar for the other functions with multiple arities
- section 2.3.5.1.1: "Problem here: "If $arg is the empty sequence, 
returns the empty sequence." We have no terminology of "sequence", we 
hav a result or we have none. I suggest, that we define that an error is 
returnd for all the cases where XPath/Xquery says that an "empty 
sequence" is returned": makes sense
- section 2.3.5.1.1: I agree we should discard those functions whose 
arguments/return types we do not support
- section 2.3.6: what is meant with "an XPath or XQuery built-in"?

Regarding the discussion points in section 3:
2 this is an issue for FLD/BLD
3 I'd say this is phase 2, as we want to have last call of the spec end 
of May
4 I don't think we need to specify binding patterns here; such binding 
patterns could be part of a document with "implementation hints", as 
discussed at the face-to-face
5 as I understood it, durations are ill-defined, so we cannot use them
6 has been superseded by the guard predicates
7:
- "Description needed here" seems to be superseded by section 2.3.7
- "Gensym a new value of type rif:bNode": we have not defined this 
datatype, and I'm not sure whether we need it; one can use rif:local instead
- lang, datatype, langMatches can be implemented, although lang is 
probably superseded by section 2.3.7
- isLiteral should also not be a problem, although we should probably 
call it something like: isDataValue, and define its interpretation as 
the union of the value spaces of all considered datatypes
- isIRI is rather more problematic, because you cannot see from a value 
in the domain whether it is denoted by an IRI, so any definition will be 
rather un-elegant. one possible definition would be to say that its 
extension in a given interpretation is the set of all elements u for 
which there is some IRI i such that IC(i)=u
- isBlank suffers from the a similar problem; the definition would be 
even more intricate. one possible definition would be to say that its 
extension in a given combined RIF-RDF interpretation plus blank node 
mapping A is the set of all elements u for which there is some blank 
node i such that A(i)=u.  this definition is very ugly, though.


Best, Jos


Boley, Harold wrote:
> This is from Axel, Harold
> 
> 
> -----Original Message-----
> From: axel@ww.ia.urjc.es [mailto:axel@ww.ia.urjc.es] 
> Sent: March 2, 2008 3:39 AM
> To: Boley, Harold
> Subject: [Fwd: [DTB] Datatypes and Built-ins first run to clean up and
> extend the initial list]
> 
> Can you forward this to the RIF list?
> It seems I cannot send it from this webmail-client to the list, I am
> behind a mail-safe firewall ;-)
> 
> thanks,
>  axel
> ---------------------------- Original Message
> ----------------------------
> Subject: [DTB] Datatypes and Built-ins first run to clean up and extend
> the      initial list
> From:    axel@ww.ia.urjc.es
> Date:    Sat, March 1, 2008 9:53 pm
> To:      public-rif-wg@w3.org
> ------------------------------------------------------------------------
> --
> 
> Dear all,
> 
> I did a first run on cleaning up the datatypes and built-ins document at
> 
> http://www.w3.org/2005/rules/wiki/DTB
> 
> What I did so far is:
> 
>  * Moving the syntax discussion for builtins to an own section (this
> might go to BLD/FLD though)
> 
>  * Added a new syntax proposal for built-ins, which is very simpe:
>      Why not just add one or two new symbol spaces for built-ins?
>    We anyway cannot really take the XQuery/XPath functions and ops "as
> is"
>    since we have a deviating semantics in some respects, see below and
>    comments in *bold* font in the document.
> 
>  * Adding "guards" and negative guards for all datatypes.
> 
>  * Adding cast functions
> 
>  * Sorting the list by Paula into functions and predicates
> 
>  * Cleaning up the syntax used a bit, e.g. istead of:
> 
> 
>     op:numeric-multiply($arg1 as numeric, $arg2 as numeric) as numeric
> 
>   I now write:
> 
>     op:numeric-divide($arg1 as TERM, $arg2 as TERM) as numeric
> 
>   since - as if i understood correctly builtin terms are uniterms as
> well -
>   TERMs will be allowed in all argument positions.
>   I should probably rather use the FLD signature definition syntax here.
> 
>   For predicates, I just droped the return type xds:boolean in Paula's
> list,  e.g.
> 
>  "
>    op:numeric-equal($arg1 as numeric, $arg2 as numeric) as xs:boolean  "
>  is now
> 
>  "
>    op:numeric-equal($arg1 as TERM, $arg2 as TERM)
> 
>   only defined if all arguments are numeric (i.e. their
>   interpretation is in the value space of xsd:integer,
>   xsd:long, or xsd:decimal), otherwise returns false.
>  "
> 
>  We run into some issues here which I pointed out in *bold* font in the
> document.
> 
> This is only a first draft, and I am struggling with the formatting of
> the new wiki... but given the limited time I had, what I could achieve
> so far.
> 
> best,
> Axel
> 
> 
> 

-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw