@Till: Got it. I agree to your opinion. The issue here for the full-text search is that many function parameters that controls the behavior of full-text search will be added in the future. Maybe this is not the issue? :-)
Best, Taewoo On Thu, Sep 15, 2016 at 3:11 PM, Till Westmann <[email protected]> wrote: > Hi, > > I think that our challenge here is, that XQuery is very liberal in the > introduction of new keywords, as the grammar is keyword free. However, they > often use combinations of words "contain" "text" to disambiguate. > AQL on the other had is not keyword free and so each time we introduce a > new > one, we create a backwards compatibility problem. It seems that for AQL > using a > function-based syntax would create fewer problems. > > Cheers, > Till > > On 2 Mar 2016, at 18:25, Taewoo Kim wrote: > > Hello All, >> >> I would like to suggest a current function name change. I am currently >> working on Full Text Search features. XQuery Full-text search spec [1] >> states that for a full-text search, the syntax is *RangeExpr ( "contains" >> "text" FTSelection FTIgnoreOption? )?*. As you see, we are going to use >> "contains text something". And we already have contains() function [2] >> that >> does a substring match. So, in order to remove possible ambiguities >> between two features, *contains()* will be renamed to *string-contains()* >> when I merge my index-only branch to the master if there is no strong >> opinion on this. Thank you. I will send another note as my merge >> progresses. Thank you. >> >> [1] https://www.w3.org/TR/xpath-full-text-10/#doc-xquery10-FTContainsExpr >> >> [2] >> https://asterix-jenkins.ics.uci.edu/job/asterix-test-full/si >> te/asterix-doc/aql/functions.html#StringFunctions >> >> Best, >> Taewoo >> >
