Re: Discovery of query capability (was: OSLC & LDP: Query Capabilities, Creation Factories & location of Dialogs)

[Steve K Speicher <sspeiche@us.ibm.com>]

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net

Martin P Pain <martinpain@uk.ibm.com> wrote
on 12/08/2014 05:07:19 AM:

> From: Martin P Pain <martinpain@uk.ibm.com>
> To: Steve K Speicher/Raleigh/IBM@IBMUS
> Cc: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 12/08/2014 05:07 AM
> Subject: Discovery of query capability (was:
OSLC & LDP: Query Capabilities,
> Creation Factories & location of Dialogs)
> 
> > > 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).
> 

A link header may make more sense, I was just getting
the concept out and showing the linkage.

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

Agree it would be good to be aligned, though I think
LDP WG is so early in its thinking here I'm not sure if any reaction would
stick longer term.
 
> Does that sound like a good idea? 
> 

Sure, I'll wait until after our next meeting to make
sure we have some agreement on the approach.

- Steve

> 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