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

Martin Pain  commented on OSLCCORE-20:

What do you mean by "a known project area"?

In my opinion, in a 'clean' API then the URI for the project area would be the URI for the service provider. i.e. they would be the same resource. (But I know not all implementations will do that, especially if the project areas are primarily accessed via a browser which use AJAX-style hash URLs). There's the oslc:details link from a service provider to a web page that describes it (i.e. the project area's home page), which might be useful for finding the right one, but I wouldn't expect that you could rely on that.

What is your expectation as to what knowledge the client has which it can use to "know" the project area? e.g. a URI, a name, an ID? If it's a user selecting it, then selection dialogs are useful (but then again it's not a known project area to the client, just the user). If they have the name, then we have dcterms:title to contain the name of the provider/area. And if they are separate resources but with a one-to-one mapping then I'd suggest the dcterms:title of the service provider is exactly the same as the name of the project area. Perhaps we ought to say that in the spec. (There's also dcterms:identifier for IDs, and although we don't include that in the resource shape for service providers, that would be the go-to property for specifying an internal identifier for the service provider. Again, we could add that to the shape in the spec.)

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