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-29) Allow for selection dialogs for ServiceProviders


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

James Amsden commented on OSLCCORE-29:
--------------------------------------

If ServiceProviderCatalog and ServiceProvider are LDPCs, then a server could provide selectionDialogs for ServiceProviders the same as any other LDPC. 

The only change in this proposal is to include the ServiceProviderCatalog oslc:selectionDialog property so that the selection dialog can be discovered either through the ServiceProviderCatalog properties or the Link headers from an OPTIONS request on a ServiceProviderCatalog (LDPC).

So this is a minor change that further unifies OSLC2 and OSLC3 discovery while providing new "meta" discovery capabilities. 

> Allow for selection dialogs for ServiceProviders
> ------------------------------------------------
>
>                 Key: OSLCCORE-29
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-29
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Task
>            Reporter: Martin Pain
>            Assignee: James Amsden
>              Labels: ready-for-vote
>
> See proposal.
> This is to support step 1.1.2 in the "A human creating a request and tracking the result." OSLC Automation-based discovery scenario here: https://wiki.oasis-open.org/oslc-core/Discovery/Scenarios#A1._Scenario:_A_human_creating_a_request_and_tracking_the_result.
> The benefits would be:
> * The server can use terminology appropriate to the partitioning being used on the server (e.g. "Project areas" (IBM Jazz) vs "Domains" (IBM RTVS) vs "Service Providers").
> * The server can provide search capabilities appropriate to the server. e.g. if there are IBM Jazz "Project areas" that are not the same thing as the Service Provider HTTP or RDF resources, then the dialog can search the "project areas" instead.
> * If the server uses nested providers, it can display the nesting appropriately. (e.g. With SPC and SP RDF resources, only SPCs can be nested, but an SP selection dialog can show SPs as nested if it makes sense for that server's users.)
> * In a way, it treats SPs the same as any other OSLC resource (i.e. the resources within Services, such as ChangeRequests and AutomationResults). Which allows us to be more consistent across OSLC (and therefore potentially will make code more reusable too).



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


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