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] Commented: (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 commented on ODATA-139:

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." 

> 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 v1.0, OData Protocol v1.0, OData URL Conventions v1.0
>    Affects Versions: WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: 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]