[OSLCCORE-29] Allow for selection dialogs for ServiceProviders - OASIS Technical Committees Issue Tracker

XML

Word

Printable

Proposal:

Hide

Add oslc:selectionDialog predicate (zero-or-many) to ServiceProviderCatalog shape, to point to a selection dialog for ServiceProviders. If appropriate, also add a comment about discovering this selection dialog via headers.

That is any of the OSLC3 discovery capabilities may be utilized on ServiceProviderCatalog or ServiceProvider resources.

Show
Add oslc:selectionDialog predicate (zero-or-many) to ServiceProviderCatalog shape, to point to a selection dialog for ServiceProviders. If appropriate, also add a comment about discovering this selection dialog via headers. That is any of the OSLC3 discovery capabilities may be utilized on ServiceProviderCatalog or ServiceProvider resources.
Resolution:

Hide

TC voted to approve the proposal as amended to apply discovery to any discovery resource.

Show
TC voted to approve the proposal as amended to apply discovery to any discovery resource.

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).