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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

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


Subject: [OASIS Issue Tracker] Commented: (CMIS-144) Full text search syntaxand semantics



    [ http://tools.oasis-open.org/issues/browse/CMIS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11538#action_11538 ] 

Florent Guillaume commented on CMIS-144:
----------------------------------------

If we don't specify a syntax, every single CMIS client will have to have a hardcoded list of vendors and each one's behavior. I don't feel that's a good way of doing interop.

What I see in projects around makes me think that ANDing of terms is what's most useful to humans using a search engine, so if there should be a minimal syntax I suggest that ANDing be the default. Note that you can implement ORing by doing several queries without great loss of performance, but only the server can AND efficiently.

Therefore my proposal 0. Specifics can be discussed, for instance if people feel that exclusion is already too much then we can have a proposal -1 that doesn't deal with term exclusion.

Case: I would leave it to repositories. Most are case insensitive in fulltext search however, isn't it?
Wildcard: that's gotta be another can of worms, so I'd leave unspecified, but I agree that it's a concern.
 


> Full text search syntax and semantics
> -------------------------------------
>
>                 Key: CMIS-144
>                 URL: http://tools.oasis-open.org/issues/browse/CMIS-144
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: Bug
>          Components: Domain Model
>    Affects Versions: Draft 0.60
>            Reporter: David Caruana
>            Assignee: Ethan Gur-esh
>
> The text search expression is defined as a <character string literal> (as defined by SQL-92).  However, the syntax and semantics of the full text search expression are repo specific.
> I remember there was some resistance to defining a 'lowest common denominator' full text search language, but I don't remember why.
> Given that we define SQL, and that query is a key use case, I think there's value in a deeper FTS definition.
> As a starting point, JCR provides minimal definition. I'm not sure we would need to much further than that to start with.

-- 
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]