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=10195#action_10195 ] 

Al Brown commented on CMIS-144:

I think you are asking to clarify CONTAINS(foo) syntax.  In particular whether or not a client can do 'foo AND bar', '+foo +bar', 'foo <NOT> bar', '+foo -bar' and the particular syntax a client can use to express:

as well as phrases.  If we standardize the above behavior, we also need to add in a capability on level of support - simple/black box vs enhanced

I am not sure it is required at this point to support a standard contains syntax in 1.0.  A lot of us implement FTS in a variety of ways - Autononmy/IDOL, Autonomy/Verity, Lucene, Omnifind, DB-specific FTS (DB2, Oracle, etc), FAST, etc.  

The main use case I am aware of is a client wanting to use single keywords in contains() - e.g., contains(foo) rather than complex FTS queries. I do not think that warrants specifying the syntax for AND, OR, NOT, phrases in contains.

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