Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net
Martin P Pain <> wrote
on 12/08/2014 05:07:19 AM:
> From: Martin P Pain <>
> To: Steve K Speicher/Raleigh/IBM@IBMUS
> Cc: "OASIS OSLC Core TC Discussion List"
<>
> 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
>
>
> <> wrote on 02/12/2014 13:57:49:
>
> > From: Steve K Speicher <>
> > To: "OASIS OSLC Core TC Discussion List" <>
> > Date: 02/12/2014 13:58
> > 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
