Uploaded image for project: 'OASIS OSLC Lifecycle Integration Core (OSLC Core) TC'
  1. OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
  2. OSLCCORE-53

Does a ServiceProvider have one Service per oslc:domain value, or does it reflect the server's desired container structure.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: Core
    • Labels:
      None
    • Proposal:
      Hide

      1. The LDPC hierarchy for v3 incremental, Link header based discovery could be identical to the ServiceProviderCatalog, ServiceProvider and Service resources, and that the Services LDPC's members could be the resources the service creates. In this case, service.creationFactory.creation === Service.

      2. Service is an LDPC in order to support the unified v2 and v3 LDPC hierarchy described in 1.

      Servers implementations are free to set the members of a Service LDPC to anything they want, possibly a place to put customized metadata, the OSLC resources managed by that Service, possibly organized in LDPCs for each different usage, or anything else that meets the implementation needs.

      Having Service be an LDPC gives servers more flexibility, not less. The LDPC has members, but we're not constraining what those members are, or their cardinality (could be none).

      Since the specification does not constrain implementations as to the content of these service LDPCs, there is no specification change required and this issue can be closed.

      Show
      1. The LDPC hierarchy for v3 incremental, Link header based discovery could be identical to the ServiceProviderCatalog, ServiceProvider and Service resources, and that the Services LDPC's members could be the resources the service creates. In this case, service.creationFactory.creation === Service. 2. Service is an LDPC in order to support the unified v2 and v3 LDPC hierarchy described in 1. Servers implementations are free to set the members of a Service LDPC to anything they want, possibly a place to put customized metadata, the OSLC resources managed by that Service, possibly organized in LDPCs for each different usage, or anything else that meets the implementation needs. Having Service be an LDPC gives servers more flexibility, not less. The LDPC has members, but we're not constraining what those members are, or their cardinality (could be none). Since the specification does not constrain implementations as to the content of these service LDPCs, there is no specification change required and this issue can be closed.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              jamsden James Amsden
              Reporter:
              martinpain Martin Pain (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: