oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Discovery of query capability (was: OSLC & LDP: Query Capabilities, Creation Factories & location of Dialogs)
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: Steve K Speicher <sspeiche@us.ibm.com>
- Date: Mon, 8 Dec 2014 10:07:19 +0000
> > 3. Those LDP containers:
> >
> > a) would provide LDP's querying mechanism.
(Is there such
> a thing? I
> > can't find it.) replacing v2's Query
Capabilities
>
> No, it is being discussed for LDP "2.0". We could
simply do
> something like this to advertise v2 query support on LDP Containers
>
> <> a ldp:DirectContainer ;
> oslc:queryType <http://open-services.net/ns/core#OSLCQuerySyntax>.
>
> or something
I'd propose using an HTTP Link header.
Similar to how LDP use a Link header with rel=type for identifying that
it is a container - which implies the semantics of a POST on the HTTP resource
- as this is giving information on how to form GET requests. (Also means
it's available in a HEAD request).
Ideally we'd use the same means of discovering
that OSLC query capability/syntax is available on that resource as LDP
will use to advertise its own query mechanism (once defined). I know this
can't go into a spec at this stage, but if one of you who is in LDP could
raise the question to get some form of consensus from that group (and,
if the consensus is a Link header, then the rel URL to use) then we can
follow that pattern.
Does that sound like a good idea?
Thanks,
Martin
<oslc-core@lists.oasis-open.org> wrote on 02/12/2014
13:57:49:
> From: Steve K Speicher <sspeiche@us.ibm.com>
> To: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 02/12/2014 13:58
> Subject: Re: [oslc-core] OSLC & LDP: Query
Capabilities, Creation
> Factories & location of Dialogs
> Sent by: <oslc-core@lists.oasis-open.org>
>
> Hi Martin,
>
> Thanks for sharing. This is timely, as I getting ready to outline
> this in more detail. I have done some work internally and on
my
> todo list for this month to publish it out. I'll comment directly
> on some of the points you've raised below.
>
> - Steve
>
>
> > From: Martin P Pain <martinpain@uk.ibm.com>
> > To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
> > Date: 12/02/2014 04:55 AM
> > Subject: [oslc-core] OSLC & LDP: Query Capabilities, Creation
Factories &
> > location of Dialogs
> > Sent by: <oslc-core@lists.oasis-open.org>
> >
> > As we move OSLC 3 to be based on LDP, I presume Query Capabilities
and
> > Creation Factories will be replaced by capabilities from LDP.
> >
> > As I'm starting to draft the Automation v3 spec, I've come to
the place
> > where I need to be able to refer to the definition of the headless
query/
> > selection and creation capabilities.
>
> I believe we don't need to define much of this in domain specs, you
> just need to leverage some basic ways that LDP and Core expose
> capabilities and clients can discover it.
>
> > This also raises the question: are we keeping the existing
> > oslc:ServiceProvider and oslc:Service resources? I see no reason
not to.
> From a pure 3.0 spec perspective, no. I see no reason to require
these.
> From a compatibility with 2.0 specs, then yes of course we'd need
to.
>
> >
> > So my expectation of how this would go is:
> >
> > 1. An oslc:ServiceProvider:
> >
> > a) which is possibly discoverable
from an
> oslc:ServiceProviderCatalog
> > b) would contain one or more oslc:Service
resources
> We could just have LDP Containers. Perhaps you could outline
the
> specific needs of what a oslc:ServiceProvider should have, so a
> client/server could satisfy a certain. Typically the needs are
that
> a client needs to interaction with a set of services that operate
on
> types of resources, such a container.
>
> > 2. These oslc:Service resources:
> >
> > a) would each identify which OSLC
domain they operate in
> using their
> > oslc:usage property
> >
> > i) (I
believe this can also exist at the
> oslc:ServiceProvider level)
> >
> > b) Link to LDP containers for each
of the resource types
> they work with
> >
> > i) (They
may have more than one container for eachresource
> > type, e.g.
> > Automation
Requests ready for execution, and
> Automation Request
> > templates)
>
> Essentially, you can think of what a "oslc:Service" (and
everything
> it contains) as an LDP:Container, annotated to provide the needs we
> had before (query, dialogs, types, shapes, usage)
>
> > c) Maybe, they would still contain
the links to the
> Creation & Selection
> > dialogs (i.e. in the same place as
v2)
> Yes
>
> Something like:
>
> <> a ldp:DirectContainer;
> oslc:creationDialog <#newDialog> ;
> oslc:resourceType auto:AutomationRequest.
>
> <#newDialog> a oslc:Dialog;
> oslc:dialog <http://example.org/ui/newDialog>;
> dcterms:title "New Automation Request".
>
> > d) (for providers wanting to be compatible
with v2:) would
> contain v2
> > Creation Factories and Query Capabilities
>
> Correct, we should keep the 3.0 specs "pure" and have a
separate
> "note" on v2 compatibility. Imagine what the 3.0 spec
would look
> like to someone who knows nothing about v2 or 2 years from now,
> should they know anything about v2?
>
> There has been some things started and actively being worked now:
>
> Core 3.0: http://tools.oasis-open.org/version-control/browse/wsvn/
> oslc-core/specs/compat.html
> ChangeMgmt 3.0: http://tools.oasis-open.org/version-control/browse/
> wsvn/oslc-ccm/trunk/supporting-docs/change-mgt-compatibility.html
>
> > 3. Those LDP containers:
> >
> > a) would provide LDP's querying mechanism.
(Is there such
> a thing? I
> > can't find it.) replacing v2's Query
Capabilities
>
> No, it is being discussed for LDP "2.0". We could
simply do
> something like this to advertise v2 query support on LDP Containers
>
> <> a ldp:DirectContainer ;
> oslc:queryType <http://open-services.net/ns/core#OSLCQuerySyntax>.
>
> or something
>
>
> > b) where appropriate, would provide
the creation
> capability (replacing
> > v2's Creation Factories)
>
> We could call a LDP Container a creation factory, that is all it is.
> Though I'm not sure if we need to carry that v2 terminology forward
in 3.0.
>
> > c) Maybe, it might be appropriate
to link from the container to the
> > creation & selection dialogs
for the resources in that
> container. So
> > (for dialogs that are specific to
a single LDP container -
> not all will
> > be) all the operations for that container
are linked from
> the container
> > itself. However, compatibility with
v2 would require that
> the dialogs
> > are linked from the oslc:Service.
>
> Not sure I'm hearing anything I disagree with but not sure I fully
> get the point. I think it would be helpful if we worked an example,
> side-by-side.
> The way to think of it, starting with a Container...build up from
> there like I mentioned before: dialogs, query, etc.
>
> > In particular, right now I need to know:
> > - Is 3a correct, or will we be keeping Query Capabilities?
>
> For at least 1st half of 2015, I think Query Capability will remain
> a thing only on open-services.net. It is there, we can use it
as
> needed. We'll need to decide what we want to do with this longer
term.
>
> > I think 3c is also an important point to decide on.
> >
> > Thanks,
> > Martin
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales
with
> number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]