OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (OSLCCORE-20) Service provider should describe domain/scope

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

James Amsden commented on OSLCCORE-20:

Email discussion between Nick and Martin that may be useful to capture here:

In Jim's issue 2, 2. Given a resource, how would a client discover information about capabilities on that resource?, Jim stated: "The problem is that if a user has a link to a resource (e.g., an RTC Project Area) that has OSLC capabilities, there's no way to navigate from that resource to the Service Provider that describes those capabilities. For example, if a user had a URL for JKE Banking (Change Management) Project Area, there is no easy way to find the Service Provider resource that would provide the URL for the query capability for that project area."

For resources that are OSLC resources (such as requirement collections or change requests), as opposed to resources that represent something that has OSLC capabilities but are not themselves OSLC resources (such as Jazz project areas), the oslc:serviceProvider property provides exactly the desired navigation. So, one way to address this specific issue is to suggest that servers with resources that represent something that has OSLC capabilities but are not themselves OSLC resources, they nonetheless add an oslc:serviceProvider property.  This is the inverse of the other approach described - to allow oslc:details to point from the service provider to this non-OSLC resource.

Nick, that approach does seem to make sense. 

However, there are some disadvantages to it too: 
The other resource has to be RDF (the odlc:details link in the other direction could point to a resource that only has a 'plain old XML' representation, depending on how we defined it in the spec/vocab). 
It means modifying the non-OSLC resource, rather than the OSLC resource, when this modification is based on the OSLC spec.

But I don't see either of them as major problems. It does make sense for the link to go from the one you have the URI for to the one you don't. Especially as clients without vendor-specific knowledge can't do anything with the vendor-specific resource so there's no need for them to discover it from the ServiceProvider.

> Service provider should describe domain/scope
> ---------------------------------------------
>                 Key: OSLCCORE-20
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-20
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>            Reporter: David Honey
>            Assignee: James Amsden
>              Labels: ready-for-vote
> OSLC 2.0 supports a service declaring a domain or scope using oslc:domain and oslc:usage. Jazz applications frequently declare a service provider for each project area. However, there is no standard way for a client to determine which service provider to use for a known project area.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]