W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2009

binding patterns [was: Re: list builtins done]

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Thu, 07 May 2009 12:25:56 +0200
Message-ID: <4A02B734.8080204@inf.unibz.it>
To: Gary Hallmark <gary.hallmark@oracle.com>
CC: Chris Welty <cawelty@gmail.com>, Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
Actually, I now have a doubt about the binding patterns with an unbound
variable for the predicates pred:string-equal, pred:date-equal,
pred:dateTime-equal, pred:duration-equal, pred:date-equal,
pred:time-equal, pred:XMLLiteral-equal, pred:matches-language-range, and
pred:text-equal. The problem is that in implementations you would need
to generate all things that are somehow equal according to the XSD
definition. For example, for dateTime, you need to generate all dateTime
values that represent the same point in time (e.g., by varying the
timezone). matches-language-range is probably even harder.

There is no problem for the datatypes for which equality and identity
are the same (e.g., string). However, for reasons of symmetry, I would
prefer to have the same binding patterns for all datatype equality
predicates.

So, I propose to remove all binding patterns involving a "u" for the
predicates pred:string-equal, pred:date-equal, pred:dateTime-equal,
pred:duration-equal, pred:date-equal, pred:time-equal,
pred:XMLLiteral-equal, pred:matches-language-range, and pred:text-equal.


Best, Jos

Gary Hallmark wrote:
> I think most PRD translators will have to detect builtins with unbound
> arguments and generate some "tricky" code because most PRD engines don't
> allow any unbound arguments to their builtins. I don't object because I
> think the few builtins that permit unbound args are quite useful.
> 
> Jos de Bruijn wrote:
>> Action completed. The only additional binding pattern (besides the
>> trivial (b...b) patterns) that I thought should be defined was for
>> pred:list-contains (b,u).
>>
>>
>> Best, Jos
>>
>> Jos de Bruijn wrote:
>>  
>>> I can do this. Please assign me an action.
>>>
>>>
>>> Jos
>>>
>>> Chris Welty wrote:
>>>    
>>>> So who will take up the issue of binding patterns for lists in Core?
>>>> Axel? Jos?
>>>>
>>>> -Chris
>>>>
>>>> Sandro Hawke wrote:
>>>>      
>>>>> I think the DTB section on RIF lists [1] is now ready for review for
>>>>> Last Call.  A few notes and questions:
>>>>>
>>>>>    * I removed the func:delete function, because           (a) it's
>>>>> not in xpath,
>>>>>           (b) it's confusingly similar to func:remove, and
>>>>>           (c) it's trivial emulated:                  func:delete(L,
>>>>> I) = func:except(L, func:make-list(I))
>>>>>
>>>>>      Some other functions are trivial emulated, but they're in
>>>>> xpath.  I
>>>>>      think the bar is higher for us adding functions.  This way, the
>>>>>      only ones we're adding are is-list, list-contains, make-list, and
>>>>>      get.  list-contains is that only the can be emulated:
>>>>>              list-contains(L, I) iff count(index-of(L, I)) > 0    
>>>>> but I think we specifically discussed that and agreed it was
>>>>>      worthwhile to have list-contains.
>>>>>
>>>>>      Obviously, if someone actually wants it, I'm okay with putting
>>>>>      func:delete back in.
>>>>>
>>>>>    * This section has examples.  I could trivially suppress them
>>>>> for now
>>>>>      (this wiki-text is generated by a program [2]), if they bother
>>>>>      people.  I like them.  They have all been checked by my demo code
>>>>>      [3].  I'm willing to make similar examples for the rest of DTB
>>>>> for
>>>>>      a later edition.
>>>>>
>>>>>    * I don't know the right binding pattern for list-contains. 
>>>>> Above, I
>>>>>      was assuming it was (b,b), but I can imagine some utility to all
>>>>>      binding patterns, and at least (b,u) seems pretty reasonable. 
>>>>> It's
>>>>>      not clear to me whether PR systems would do what I'm imagining
>>>>> with
>>>>>      that, but it'd be nice to write rules like:
>>>>>
>>>>>          forall M (                   if 
>>>>> list-contains(eg:list_of_friends, M)
>>>>>            then eg:is_friend(M)
>>>>>          )
>>>>>
>>>>>      Without it, I guess you'd need some much more cumbersome
>>>>>      tail-recursive rules like this:
>>>>>
>>>>>          friend_list(eg:list_of_friends)              forall L M (
>>>>>            if   friend_list(L) and
>>>>>                 get(L, 0) = M
>>>>>            then eg:is_friend(M)
>>>>>          )
>>>>>          forall L  (
>>>>>            if   friend_list(L) and
>>>>>                 count(L) > 0
>>>>>            then friend_list(sublist(L, 1))
>>>>>          )
>>>>>
>>>>>      PR folks, what do you want, there?
>>>>>
>>>>> I think that it.  This complete ACTION-760.
>>>>>        -- Sandro
>>>>>
>>>>>
>>>>> [1]
>>>>> http://www.w3.org/2005/rules/wiki/DTB#Functions_and_Predicates_on_RIF_Lists
>>>>>
>>>>>
>>>>> [2] http://dev.w3.org/cvsweb/2009/rif/list_builtins.py
>>>>>
>>>>>
>>>>>         
>>
>>   
> 

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller


Received on Thursday, 7 May 2009 10:26:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:08 GMT