OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Issue Comment Edited: (ODATA-139) New system query option $search for free-text search within an entity set


    [ http://tools.oasis-open.org/issues/browse/ODATA-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32402#action_32402 ] 

Stefan Drees edited comment on ODATA-139 at 2/25/13 1:33 PM:
-------------------------------------------------------------

While implementing this, I reread the proposal, esp. the sentence: "No expressions, functions or parentheses. " and tried to relate this to the available operators AND, OR and NOT.

If I do not have parentheses, then I can't mix AND (implicit or explicit) with OR, at least in a memorizable, understandable and useful way, right ;-?

$search=foo bar OR baz 

Shall this be evaluated like: 
  $search=(foo bar) OR baz 
or like:
  $search=foo (bar OR baz) 

No matter which binding "wins", the clients might have meant the other one ... at least in my experience. 
Resorting to a set of N queries is often not acceptable to the user, when all they want to ask is eg.: 
  "Which entities have either "foo AND bar" or "baz" somehow associated with?"

The binding of NOT as only to the directly following term to the right seams somehow OK, 
**but** would also profit from parentheses, wouldn't it?

May we include parentheses (as precedence/grouping constructs) to allow full symmetric usage of the operators in  (OR, AND, NOT) ?

What I suggest, is a MAY w.r.t. a conforming service but so that it is at least described/suggested in the work products. 

So I propose to change the sentence: "No expressions, functions or parentheses." into something like: 
"No expressions or functions. An OData server MAY allow parentheses inside the $search expression to group subexpressions with respect to precedence." 

PS: The linked description to the bing syntax also shows parentheses as prominent grouping construct.

Update: A first stash at a sub grammar for the $search=searchExpr part [MSearch.g4](https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/spec/grammar/ANTLR/MSearch.g4?sc=1) is in SVN which adds grouping to yield a well cut mini search capability.

This DSL should be usable in the scenarios of this ODATA-139, ODATA-222 "free-text search within a property" and ODATA-228 "Specify $search for free-text search within a OData Service and specify $search for free-text search within an entityContainer". 

      was (Author: sdrees):
    While implementing this, I reread the proposal, esp. the sentence: "No expressions, functions or parentheses. " and tried to relate this to the available operators AND, OR and NOT.

If I do not have parentheses, then I can't mix AND (implicit or explicit) with OR, at least in a memorizable, understandable and useful way, right ;-?

$search=foo bar OR baz 

Shall this be evaluated like: 
  $search=(foo bar) OR baz 
or like:
  $search=foo (bar OR baz) 

No matter which binding "wins", the clients might have meant the other one ... at least in my experience. 
Resorting to a set of N queries is often not acceptable to the user, when all they want to ask is eg.: 
  "Which entities have either "foo AND bar" or "baz" somehow associated with?"

The binding of NOT as only to the directly following term to the right seams somehow OK, 
**but** would also profit from parentheses, wouldn't it?

May we include parentheses (as precedence/grouping constructs) to allow full symmetric usage of the operators in  (OR, AND, NOT) ?

What I suggest, is a MAY w.r.t. a conforming service but so that it is at least described/suggested in the work products. 

So I propose to change the sentence: "No expressions, functions or parentheses." into something like: 
"No expressions or functions. An OData server MAY allow parentheses inside the $search expression to group subexpressions with respect to precedence." 

PS: The linked description to the bing syntax also shows parentheses as prominent grouping construct.
  
> New system query option $search for free-text search within an entity set
> -------------------------------------------------------------------------
>
>                 Key: ODATA-139
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-139
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ABNF Construction Rules, OData Protocol , OData URL Conventions 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_WD01
>
>
> Searching a list of entries by entering a free-text search phrase in a single input field is a very common UI pattern in mobile and browser-based applications.
> Translating this (typically case-insensitive) search phrase into an OData filter string is cumbersome and error-prone.
> A better alternative is providing a specialized query option that takes a search term and allows the server to interpret this search term.
>     GET ~/Orders?$search=blue
> could return sales orders that somehow match the phrase "blue", without the client needing to specify where this phrase may occur. It even could appear in related entities, e.g. the description of one of the products ordered.
> This is comparable to Level 0 Conformance in CQL, see ODATA-3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]