- From: Gary Hallmark <gary.hallmark@oracle.com>
- Date: Thu, 7 May 2009 13:42:41 -0700
- To: Jos de Bruijn <debruijn@inf.unibz.it>
- Cc: Chris Welty <cawelty@gmail.com>, Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
+1 to require all builtin equality tests to have bound args On Thu, May 7, 2009 at 3:25 AM, Jos de Bruijn <debruijn@inf.unibz.it> wrote: > 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 > -- Cheers, Gary Hallmark
Received on Thursday, 7 May 2009 20:43:23 UTC