Re: [oslc-core] OSLC & LDP: Query Capabilities, Creation Factories & location of Dialogs

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

I took the liberty to sketch in more detail
what I meant from some of my comments below.  I've put in a webpage
how we can build upon the LDP Container concept many of the things we depended
on in 2.0.  Requires some new vocabulary as sketched but pretty simple
and minimal, perhaps even cleanly layers on queryCapability/creationFactory.

https://wiki.oasis-open.org/oslc-core/Discovery

Feedback welcome, we can review at upcoming
meeting.

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



From:      
 Steve K Speicher/Raleigh/IBM@IBMUS
To:      
 "OASIS OSLC Core
TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:      
 12/02/2014 08:58 AM
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 each resource 
> 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