cmis message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cmis] CMIS stored query?
- From: Scott Malabarba <scott.malabarba@us.ibm.com>
- To: cmis@lists.oasis-open.org
- Date: Wed, 30 Mar 2011 10:59:45 -0700
I think it's well understood that any new
feature will be added to all bindings.
We use AtomPub examples below just for
informal exposition.
I don't quite follow your concern about
semantics. Any semantics would
be captured in the names of a saved
query and its parameters -- same
as with folders and object properties.
Saved queries should be incorporated
into the domain model in a way that's
generic and matches the way other objects
are modelled. The server should
not return a bunch of repository-specific
data that standard clients will not
recognize. Does that help?
Good point about scenarios. Here,
again, are two I'm thinking of:
- Virtual folders. Containers
that look and act like folders but are backed
by a query or some other constraint,
rather than filing.
- Taxonomy-driven systems. Some
CMS systems rely mostly on metadata
and use folders lightly, if at
all. The spec has strong support for creating
and updating objects in this
scenario but leaves the work of retrieving them
to the client application (which
must formulate queries). Done right, saved
queries would enhance interoperability
because a server could present a
common taxonomy to multiple standard
clients. Without it, only clients with
custom queries built in could
retrieve content in a meaningful way.
Regards,
Scott
From:
Florian Müller <florian.mueller@alfresco.com>
To:
cmis@lists.oasis-open.org
Date:
03/30/2011 10:14 AM
Subject:
Re: [cmis] CMIS
stored query?
Saved queries/search templates/parameterized queries
are rather useless
in an interoperability scenario if the semantics are undefined. If a
client doesn't know what the result set means, it will not execute the
query.
Rather than talking about how repository features can be pushed through
CMIS, we should talk about the scenarios that we want to cover. If this
results in domain model extensions, I am all for it.
We should also avoid designing features from a binding perspective.
Everything we add to the domain model should (must) work later with all
bindings and we have three of them in CMIS 1.1.
Regards,
Florian
On 30/03/2011 01:55, Derek W Carr wrote:
> I am interested in expanding this support. In our implementation
of CMIS
> in Lotus Connections, we use this feature to advertise system queries
like
> files shared with me, files shared by me, trash, etc. which
were
> equivalent to virtual folders in our system. We chose to make
the results
> of the GET operation be a list of virtual folders that clients could
> navigate like any other folder using the 'down' link relation to get
the
> results. We do not yet have a need to persist new queries, but
we would
> like to see the domain model introduce better support for getting
system
> managed queries.
>
> Thanks,
> ---------------------------------------
> Derek Carr
> IBM Collaboration Solutions
> (919) 254-8592 (t/l 444)
> ---------------------------------------
>
>
>
> From:
"Churchland, David"<david.churchland@hp.com>
> To:
Scott Malabarba/Costa Mesa/IBM@IBMUS
> Cc:
"cmis@lists.oasis-open.org"<cmis@lists.oasis-open.org>
> Date:
03/29/2011 05:56 PM
> Subject:
RE: [cmis] CMIS stored query?
>
>
>
> I am certainly interested in the virtual folder model, also search
> templates / parameterized queries.
>
> From: Scott Malabarba [mailto:scott.malabarba@us.ibm.com]
> Sent: Wednesday, 30 March 2011 8:44 AM
> To: Churchland, David
> Cc: cmis@lists.oasis-open.org
> Subject: Re: [cmis] CMIS stored query?
>
> I'm interested. It'd be a useful feature and would provide better
support
> for taxonomy-driven systems.
> I think supporting search templates / parameterized queries would
be pretty
> important.
>
> Any interest in allowing POST to a stored query? Say, for example,
if the
> atom entry returned for a given stored query has the
> <cmis:allowsPost>true</cmis:allowsPost>
> property, then the client can post an object to the query's entry
URL. The
> server will create an object with metadata that matches the query.
> The use case I have in mind is virtual folders: I want the virtual
folder
> backed by my stored query to act like a real folder and let me
> drag-and-drop content into it.
>
>
>
>
>
> From: "Churchland, David"<david.churchland@hp.com>
> To: "cmis@lists.oasis-open.org"<cmis@lists.oasis-open.org>
> Date: 03/29/2011 02:14 PM
> Subject: [cmis] CMIS stored query?
>
>
>
>
> Here is a paragraph in the REST binding documentation that hints at
a
> nascent stored query capability in CMIS:
>
> This is a collection for processing queries. If the implementation
supports
> GET on this collection, then the implementation SHOULD at least return
a
> feed consisting of zero or more atom entries. These atom entries should
> represent persisted objects related to query such as persisted queries,
> long running queries or search templates.
>
> Does anyone else have an interest in incorporating this (as an optional
> capability) into the domain model, e.g.:
> · getQuery,
> · createQuery,
> · deleteQuery
> · updateQuery
> · query object supported in query
>
> My interest in this is mostly about having shared navigational shortcuts,
> for example a stored query of my favorite documents which I can access
both
> from my Desktop client and my mobile device client.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS
at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]