Re: [oslc-core] Grouping related containers (was: OSLC & LDP: Query Capabilities, Creation Factories & location of Dialogs)

Hey Martin,

Responses below...

> From: Martin P Pain <>

> To: Steve K Speicher/Raleigh/IBM@IBMUS

> Cc: "OASIS OSLC Core TC Discussion List"
<>

> Date: 12/04/2014 05:52 AM

> Subject: [oslc-core] Grouping related containers
(was: OSLC & LDP: Query 

> Capabilities, Creation Factories & location of Dialogs)

> Sent by: <>

> 

> Steve, 

> 

> In your "Discovery" document, section "Domain / types
supported" [1] (first 

> of all I think you missed the oslc:resourceType predicate, as the
example 

> doens't match your text. I've added it in for you) you raise the questions:

> 

> 1. Which dialog do I use for Requirements? 

> 2. Can a create ex:Story resources on this container? (ie are these
types 

> supported for creation? or also for query?) 

> 3. Can I query for oslc_cm:ChangeRequests? 

> 

> If all of those resource types (for this container) use the same dialogs,

> have the same creation operations available (i.e. either resources
of any of

> those types can be created, or of none), and have the same query operations

> available (i.e. either resources of all those types can be queried,
or none 

> of them) then I think having one container for all three is fine,
as you use

> the existing mechanisms (or whatever container-level mechanisms we
come up 

> with) to answer those questions. 

> 

> But as soon as you have different operations for different types,
I think 

> you need different collections. 

> 

> e.g. in OSLC Automation, a provider is likely to have a read-only
collection

> of Automation Plans, a read-write collection of Automation Requests,
and a 

> read-only list of Automation Results. So the Automation request header
would

> be the only one with an Accept-Post header, and the only one with
a creation

> dialog on it. They would all (probably) have selection dialogs. 

> 

Makes sense, this is how it worked in v2 as well.

> However, given that these three containers are tightly related, it
would 

> make sense to group them. So, I guess we'd put those three collections
in a 

> collection. Do you think there's any need to identify more about that
collection? 

> 

In v2, we bundled these into a single resource called
an oslc:Service

I'm not sure we really need a container for 3 fixed
things, can this not be achieved by just linking the containers together?

Thinking about what 1 URL someone would give for configuration,
they could give the AutoPlan container.  From that, they would be
able to find/navigate the other containers.  Would this work for Automation
needs?

> If we have any dialogs that apply to more than one resource type,
then they 

> could go on that collection. (But then perhaps we have different semantics

> between a creation dialog that creates resources as members of the

> collection that dialog is linked from, and a creation dialog that
creates 

> something related to [or a child of] resources in that collection).
I guess 

> I need to work through the Automation scenarios and see what requirements
we

> have on it. 

>

Perhaps these could be handled by having specialized
predicates on a container, such as oslc_auto:relatedRequestDialogs (I'm
making this completely up) but the case of creating something "related".
 Though I think it would be better just to have a separate "requests"
dialog.

- Steve

 

> [1] https://wiki.oasis-open.org/oslc-core/Discovery#Domain_.2BAC8_Types_supported

> 

> 

> <> wrote on 02/12/2014 21:40:39:

> 

> > From: Steve K Speicher <> 

> > To: "OASIS OSLC Core TC Discussion List" <>

> > Date: 02/12/2014 21:40 

> > Subject: Re: [oslc-core] OSLC & LDP: Query Capabilities,
Creation 

> > Factories & location of Dialogs 

> > Sent by: <> 

> > 

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

> > > 

> > Date:        12/02/2014 08:58 AM 

> > Subject:        Re: [oslc-core] OSLC &
LDP: Query Capabilities, 

> > Creation Factories & location of Dialogs 

> > Sent by:        <>

> > 

> > 

> > 

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

> > > To: "OASIS OSLC Core TC Discussion List" <>

> > > Date: 12/02/2014 04:55 AM 

> > > Subject: [oslc-core] OSLC & LDP: Query Capabilities,
Creation Factories & 

> > > location of Dialogs 

> > > Sent by: <> 

> > > 

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