[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=61469#comment-61469 ] 

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

Jim, I think I like everything you said in your previous comment (and that together with the correction of "members" to "properties" in the spec also helps), but it does raise some more questions:

1. We're now not saying anything about what the members of a Service (that must be an LDPC) are. So why is it useful to say that a Service MUST be an LDPC if clients can't have any expectation before of what they might find in it or what they might create in it. (Of course I can see that some servers might find it useful to make it an LDPC, but I can't see why we have to force all servers to make it LDPCs if clients will need to use the link headers to find out what it's a container of - they might as well just find out whether or not it's an LDPC from the headers too.) So why are we saying that Services MUST be an LDPC, not MAY? (The answer to the next question may answer this one).

2. If a Service may refer to multiple LDPCs, how does a client that only wants to use LDPCs for discovery (the specific OSLC-defined LDPCs - SPCs, SPs, etc) find those LDPCs referred to by the Service? From an SPC it can find SPs (and other SPCs) by looking at the members in ways defined by LDP. From an SP it can find Services by looking at the SP's members in ways defined by LDP. But from a Service... it has to look at the oslc:creationFactory properties to find the creation URIs in order to find the LDPCs. If LDP-based discovery is supposed to work on its own, without the static SPC-based one, isn't there a missing link here?
I think I'm in favour of saying that the answer to this question lies with the domain (as specified by the oslc:domain property on the Service). But we could identify some common patterns:
a) That the Service can be an LDPC of the domain resources that are from that Service's domain and that belong to that ServiceProvider (i.e. the resources created/queried by that Service).
b) That the Service can be an LDPC of LDPCs containing the resources form (a).
c) Perhaps a third pattern that addresses the idea that Servics might share LDPCs, as you said. Perhaps (b) already allows for that, as long as each of those LDPCs can be in multiple Service-LDPCs, and except that the LDPCs might contain resources from other domains (which the QueryCapability resource son the Service might not be able to return). But I don't think that's a problem.
Note that with these 2/3 patterns I'm not saying that the client needs to detect which one the server is using. I'm saying that the domain should define which one to use (or another approach altogether). But then, for each existing OSLC domain, we'd have to say what the approach is.

(How does question 2 affect question 1? If, for all OSLC-defined domains, we specify what the members of the Service-LDPC should be, then the only result of the MUST/MAY decision in question 1 is for oslc:domain values defined by vendors or other parties. So I think the question still stands.)

3. If we take my approach for question 2, then that makes the oslc:domain value very important even in LDPC-based discovery. Perhaps it is a candidate for a Link header? (Although that would result in duplication).

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