OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Grouping related containers (was: OSLC & LDP: Query Capabilities, Creation Factories & location of Dialogs)


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.

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?

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.

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

<oslc-core@lists.oasis-open.org> wrote on 02/12/2014 21:40:39:

> 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 21:40
> Subject: Re: [oslc-core] OSLC & LDP: Query Capabilities, Creation
> Factories & location of Dialogs

> Sent by: <oslc-core@lists.oasis-open.org>
> 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.
> Feedback welcome, we can review at upcoming meeting.
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web ->
> 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 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 <
>   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:
> oslc-core/specs/compat.html
> ChangeMgmt 3.0:
> 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 <
> 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]