search

jamsden / oslc-core-test

0 stars 0 forks source link

Ian to add scenario to https://wiki.oasis-open.org/oslc-core/DelegatedUIUseCases #15

Closed jamsden closed 5 years ago

jamsden commented 5 years ago

What specifically is required? Is there an undocumented, but required use case that is not currently supported by the draft specifications?

jamsden commented 5 years ago

From: martinpain - I believe this came from the comment at 07:20 in this meeting https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2015.02.05 :
"Ian: How can an observer influence what can be picked in a delegated dialog?"

To which the response was:
Sam: One way to do this is to have multiple selection dialogs, each with a different filter. Another approach might be using postMessage to send messages between the observer and the dialog
ACTION: Ian to add scenario to https://wiki.oasis-open.org/oslc-core/DelegatedUIUseCases

I don‘t fully understand the question.

jamsden commented 5 years ago

Ok, I get it. A client might want to control what‘s available on a selection dialog. For example, consider a project that has 12000 requirements. If a client wanted to select a requirement, they likely wouldn‘t want to have to choose from all 12000. They need some way to narrow down the selection list to something more manageable.

Sam‘s answers are correct. The server could organize requirements in different LDPCs (or Services creationFactories), and the client could choose one of those.

But ultimately its up to the server creating the selection dialog to decide how best to support their client needs. For example, a selection dialog can be designed to display folders of requirements, use tags to focus the selection, provide regular expression matching, or even some server supported query mechanism. This is all outside the scope of OSLC which only specifies how the client discovers the dialog, and how the client interacts with the dialog to resize, cancel, or get the selected resource URIs. What‘s in the dialog iframe is entirely up the the server and should be transparent to the client application, but visible to the user.

We can discuss this, but I think it can probably be closed.

jamsden commented 5 years ago

From: martinpain - Use case from OSLC Automation:
OSLC Automation has some related resources, two of which are AutomationPlans and AutomationRequests. An AutomationPlan can have zero or more AutomationRequests - and it is expected to increase over time. In this use case the UI consumer wants a user to select one AutomationRequest for a given AutomationPlan from the UI provider, without listing all AutomationRequests for all AutomationPlans on the server.

Existing non-standard implemention:
The UI consumer POSTs to the selection dialog URI some RDF that contains solely the triple "<> oslc\_auto:executesAutomationPlan ". (This is a copy of the pre-fill on creation dialogs.) The dialog then displays only the AutomationRequests that contain such a property.

I‘m not advocating this as a solution to standardise, but just as a data point of prior art.

jamsden commented 5 years ago

Ian‘s scenario was included in the delegated dialog spec.