[OASIS Issue Tracker] (OSLCCORE-53) Does a ServiceProvider have one Service per oslc:domain value, or does it reflect the server's desired container structure.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61428#comment-61428 ] 

Martin Pain commented on OSLCCORE-53:
-------------------------------------

The entire discussion in emails:

19. §5 intro and §A.3 (Service shape) [in the discovery document]: A.3 says that a Service is an LDPC, but I can't find anything that says what its members should/could be. SPCs' and SPs' members are described at the end of the first bit of §5.0.
19b. The descriptions of the shapes for SPCs and SPs should probably re-state what their members are expected to be.

<jra>I added LDPC to the descriptions of all shape properties that are LDPCs: SPC: serviceProvider, serviceProviderCatalog; SP: service; Service: creationFactory. queryCapability might be an LDPC too, but that might be implementation dependent and/or depend on what the eventual LDP Query Syntax becomes.</jra>

<MPP>I'd like to suggest these further changes:
A.1 SPC:
"An LDPC describing an OSLC Server that offers one or more Service Provider LDPCs (see below), MAY also organize the Service Providers in one or more Service Provider Catalog LDPCs to enable OSLC clients to find Service Providers offered. The members of these catalogs may include other nested catalogs as well as service providers."
A.2 SP:
"A Service Provider LDPC whose members are the services offered by an OSLC implementation"
A.3 Service:
"A Service LDPC whose members are the resources owned by the Service's Service Provider and that are also of types defined by the oslc:domain value on the Service. The Service resource also describes specific services offered by a Server that implements an OSLC domain specification, and the URIs to use for those services in the context of that OSLC domain and that Service Provider." (please review this suggestion carefully, as it may not be what we agreed as a TC when discussing LDPCs).</MPP>

<jra>Done, with some slight modifications. In particular, we did not specify what domain (or other) resources must be in a Service LDPC, leaving that choice up to the server. All that is required to do that is for the server to include the right link hearders, and for the creationFactory URI to be the URI of the Service. From the client's perspective, it doesn't matter what LDPC the domain resources are in. They will just use the LDPC URI in the creationFactory or as discovered through link headers on LDPCs they might navigate to.

Also, there's no need to restrict a Service to OSLC domain resources. Any resouce could be discovered.


A.1 SPC:
"An LDPC describing an OSLC server that offers one or more ServiceProvider LDPCs. Servers MAY also organize the ServiceProviders in one or more ServiceProviderCatalog LDPCs to enable OSLC clients to find ServiceProviders offered. The members of these catalogs may include other nested catalogs as well as service providers."

A.2 SP:
"An LDPC whose members are the Service LDPCs offered by an OSLC server"

A.3 Service:
"An LDPC whose members describe specific services offered by a server, and the URIs to use for those services in the context of that ServiceProvider.
</jra>

<MPP>I disagree with the Service one, as I don't expect that the creationFactory/queryCapabilitie/dialogs/etc will be members of the LDPC. Instead, I see them as just having links/triples from the Service (with their own properties inlined, of course). If the creation factory's creation URI is expected to point to the Service's URI, to use the LDP-defined creation semantics:
1. Do we tell the readers that?
2. That means that the Service is an LDPC whose members are the resources that are created by the creation factory/ies and creation dialog/s in that Service (and probably also the resources that are retrievable by the query capability/ies and selection dialog/s). So we could say that.
Revised suggestion:
"A resource that describes the creation and discovery (selection) of resources of one or more specific types in the context of that ServiceProvider. The scope of a Service may be an entire OSLC domain (or 3rd party-defined domain) within that ServiceProvider, or a server may have a Service for each LDPC in its existing or desired architecture. Each Service may itself be the LDPC of the resources are created or discovered through it."
However I don't like the idea of allowing arbitrary separation of resources between Services. My understanding of v2 is that a user never needs to select a Service resource (where they may have to select a SP or a nested SPC based on their title) - the client should know what domain it is looking for, so it selects Service from the SP in question based on that domain. According to OSLCCORE-23, we agreed that "Service is the point at which Domain specifications specify their specific service capabilities." - which suggests the tie between domains and Service resources. Of course, it doesn't have to be an OSLC-defined domain, but in my opinion it must be a value of the oslc:domain property on the Service. And that it is unreasonable to expect clients to be able to work with two Service resources with the same oslc:domain value, unless explicitly permitted by that domain.
So I think we have a question to answer, which probably requires its own ticket: Do we keep the one-to-one relationship between Service resources and oslc:domain values from v2 (within the context of a single SP, and if that understanding of v2 is correct), or do we re-define it and suggest/require that a Service is one-to-one with an LDPC (if not exactly the same resource) in the server's desired organisation of containers?
The benefit of the former is that clients have fewer options to present to users, and that v3 servers are more likely to work with v2 clients (although that could do with verification). The benefit of the latter is that the server's organisation of containers is exposed in the OSLC data, but this comes at the cost of complexity for the clients.
I've raised OSLCCORE-53 for this.</MPP>

> Does a ServiceProvider have one Service per oslc:domain value, or does it reflect the server's desired container structure.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-53
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-53
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Martin Pain
>            Assignee: James Amsden
>
> In OSLCCORE-23 we agreed that a Service resource should be an LDPC, but didn't state what its members were. My reading of that ticket's proposal is that the members are defined by the domain.
> In recent emails, there has been a discussion about what the members of a Service should be. My latest comments that triggered me to raise this ticket:
> According to OSLCCORE-23, we agreed that "Service is the point at which Domain specifications specify their specific service capabilities." - which suggests the tie between domains and Service resources. Of course, it doesn't have to be an OSLC-defined domain, but in my opinion it must be a value of the oslc:domain property on the Service. And that it is unreasonable to expect clients to be able to work with two Service resources with the same oslc:domain value, unless explicitly permitted by that domain.
> So I think we have a question to answer, which probably requires its own ticket: Do we keep the one-to-one relationship between Service resources and oslc:domain values from v2 (within the context of a single SP, and if that understanding of v2 is correct), or do we redefine it and suggest/require that a Service is one-to-one with an LDPC (if not exactly the same resource) in the server's desired organisation of containers?
> The benefit of the former is that clients have fewer options to present to users, and that v3 servers are more likely to work with v2 clients (although that could do with verification). The benefit of the latter is that the server's organisation of containers is exposed in the OSLC data, but this comes at the cost of complexity for the clients.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)