Re: [oslc-core] Delegated Dialogs 3.0 Ready for Review

[Martin P Pain <martinpain@uk.ibm.com>]

> > What about a selection dialog that allows creation?
> > ...
> 
> It's a good use case and probably not hard to add. A few ways we could
> do it:
> 
> 1. Add a new Link relation that indicates both creation and selection.
> 2. Add a multivalue RDF property in the descriptor to indicate the
type,
>    possibly in addition to (1). Clients can then see it's
both.
> 3. Let clients simply check if the same dialog descriptor URI is in
both
>    the creation and selection links.
> 
> Thoughts on what's best?

I don't like the idea of proliferation of Link header
rel types for combinations of other ones.

As this is a more advanced use of dialogs, it could
be limited to the RDF version, so the creation-and-selection one would
be identified solely as selectionDialog in the Link headers, and in the
the RDF could say <URI of creation-selection dialog> oslc:includesFunctionalityOf
<URI of selection-only dialog>.(This would also allow exposing information
of other includes-functionality-of relationships, such as a wizard that
allows creation of an AutomationRequest plus location of its AutomationResult
- see OSLC Automation).
However if you didn't have a selection-only dialog,
instead only having the combined one, that wouldn't work so well.

And it is starting to feel over-complicated...

(2) would be my next preference.


> > Appendix C mentions the "oslc-response:" prefix but
the example
> > doesn't use it. As that is the only place this JSON is used,
I
> > suggest we include the pefix in the example.
> 
> Since this section is about the JSON format, I wanted it to be valid
> JSON. Maybe I can update the wording to make things very clear.

If we don't mind the verbosity, we could have an example
of both. That should make it very clear.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU