[OASIS Issue Tracker] (OSLCCORE-23) Should a ServiceProviderCatalog or ServiceProvider resource be an LDPC?

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

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

Martin Pain  commented on OSLCCORE-23:
--------------------------------------

I suggest we take this to the TC in the next meeting, and ask if anyone would second the proposal to require SPCs and SPs to be LDPCs. (I've added this as "proposal to change" in the "proposal" field above). I expect no one will second it, in which case we will drop it. But I think it's important that it should be an explicit TC decision, seeing as LDP compatibility is one of the driving factors for v3. (I'd also like that to be done in a meeting and not on the mailing list - in order to avoid making a decision by inaction - although we can prompt discussion on the mailing list beforehand).

The motivation for the proposal for the change is to leverage LDP (seeing as it would not be incorrect to say that SPs are "members of" or "contained by" SPCs, so we could use LDP as the standard way of representing that - especially as v3 is supposed to be based on LDP).
The motivation for not accepting it would be the implementation burden on server implementers.

I'm happy for this to be voted on at the next meeting (or not, if no one seconds it in the meeting) - I expect it will not be accepted, but I think it should be an explicit TC decision.

> Should a ServiceProviderCatalog or ServiceProvider resource be an LDPC?
> -----------------------------------------------------------------------
>
>                 Key: OSLCCORE-23
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-23
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> OSLC 2.0/3.0 compatibility re-introduces the OSLC Core 2.0 ServiceProviderCatalog (SPC), ServiceProvider (SP) and Service resources. These resources provide a somewhat static, up-front discovery capability to access information about OSLC resources and capabilities supported by a server.
> OSLC Core 3.0 also utilizes Link headers in response to OPTIONS or HEAD request on LDPCs to dynamically discover information about OSLC resources and capabilities supported through that LDPC. 
> Although these are somewhat overlapping approaches to discovery, they are both useful in practice and can be complimentary, balancing the convenience of up-front static discovery by parsing a few resources, and more dynamic, flexible discovery through introspection of LDPCs. In any case, the OSLC Core 2.0 discovery approach is required for compatibility.
> There may be a way to normalize these by requiring that ServiceProviderCatalog, ServiceProvider and Service resources are also LDPCs. This may allow server implementations to dynamically generate the service provider resources from the LDPC and may simplify the server implementation of OSLC Discovery, and eliminate data redundancy.
> However, there's a potential problem with 2.0 SPC and SP's being LDPCs. A GET on an LDPC must also return the contents of the container in the ldp:contains property of the RDFSource resource response body. That may be a large amount of data for any given LDPC that would be inappropriate for SPC discovery. LDP supports the use of the Prefer request header to allow the client to give the server a hint on what content is desired in the response, and possibly the omit-parameter with ldp#PrefereContainment could be used to get the LDPC without any of its content element URIs. However, an OSLC 2.0 client would not know anything about these headers.



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