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

James Amsden commented on OSLCCORE-23:
--------------------------------------

Recommendation: LDPCs Link headers can specify rel='type' with values: ldp:Container and/or ldp:BasicContainer, and one of oslc:ServiceProviderCatalog,  oslc:ServiceProvider or oslc:Service.

This essentially adds OSLC2 discovery by simply adding some additional properties to LDPCs. All the OSLC3 discovery approaches and OSLC2 discovery approaches work on the same resource, without any change. Clients are free to ignore information they don't need to use. This provides a convenient means of extending discovery information with additional properties on LDPCs that have designated OSLC types. It adds no additional discovery complexity to OSLC3 discovery since clients are already expected to be able to get the RDF properties of an LDPC. These properties can now optionally be specified by OSLC2 service discovery resource types. 

Potential Issues:

OSLC2 clients accessing an OSLC3 Service Provider will now get the service provider properties, but will also get the contents of the LDPC. There is a Prefer header to control what information is returned on an LDPC, but an OSLC2 client wouldn't be expected to know those headers.

Current OSLC2 clients might depend on the specific RDF/XML representation of these discovery resources (what's in-lined where). This would be a bad practice to enforce on OSLC3 LDPCs, but might be necessary.


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