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

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

"Resource selection: when a user of a web application
and needs to pick a resource managed by another application "
- remove "and".

What about a selection dialog that allows
creation? It would be useful to be able to indicate that to the client
so they can offer a single option (if that's what they want to do). As
this stands, they could have three Link headers: one selectionDialog to
dialog A, one creationDialog to dialog A, and one creationDialog to dialog
B (the creation-only one). But clients not looking out for the creation-and-selection-dialog-at-same-URI
might not know which of the creationDialog ones to pick for the standard
creation dialog. Does anyone think this use case would be worth supporting?
It's already on the use cases wiki page: https://wiki.oasis-open.org/oslc-core/DelegatedUIUseCases#Selection

Example 7 dialog URI is the descriptor
URI from the previous example. should end with "/form2

ex 8 " Make sure the message originated
from example.com." might be better to say "from the expected
OSLC Server".

5.2 "Once the user has created,
selected, or cancelled, send notification using postMessage to the page's
parent window, passed in event.data string, that is prefixed with "oslc-response:"."
"canceled" -> "cancelled"
Also I suggest: "...parent window,
passing the URI of the created or selected resource in the oslc:results
JSON format in the event.data string, that is prefixed..."
or just omitting the bit about "event.data"
in the sentence as it stands - if we're not saying everything about how
to put the data in the postMessage call, then mentioning event.data seems
to have no value. The terms "oslc:results", "oslc:label"
and "rdf:resource" seem to only be in the example, not in the
text (at least having only read to this point), so I don't see why event.data
needs to be any different, and it seems to stick out a bit where it is.
(A link to appendix C might also be
appropriate.)

5.3 is ambiguous as to whether it's
talking about the dialog URI or the dialog descriptor URI. The examples
use the URI used for the descriptor by the previous examples, which I expect
is inconsistent.

5.3: We mention oslc:resourceShape and
then immediately follow it by an example which is not related. It might
be useful to have an example, but even if we don't I'd suggest we put a
sentence before the example saying what we're about to show an example
of.

6.3.10: Should we mention dynamic resizing
earlier, in the non-normative text? Otherwise the only reference to it
is buried in the normative compliance statements.

6.4.1: Slight improvement in clarity:
"Servers MAY allow clients to prefill creation dialogs by the client
sending an HTTP POST request to the dialog descriptor URI where the entity
body is a resource representation describing the initial values. "

Appendix A doesn't mention the term
"dialog descriptor". I'd suggest it should, probably in the summary,
possibly in the section title as well if possible.

Appendix B - vocab: selectionDialog
and creationDialog could say something about the type of resource they
are likely to be pointing to (e.g. "expected to point to a dialog
descriptor"), and possibly about the meaning of the subject URI on
the contect of the dialog, e.g. that the dialog is to select/create a resource
from/in the context of the subject/anchor of the link.

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.
We could also mention in this appendix
that this JSON goes in the "data" property of the postmessage
event, if we remove the mention of event.data further up as I have suggested.



Also, looking through the DelegatedUIUseCases
wiki page:

General.1: It mentions "mobile-specific
guidance", which we haven't addressed.
General.2: I believe we dismissed this
at previous TC meetings - the spec correctly says that the UI of the dialogs
matches the embedded tool, not the embedding tool.

ConfigContext.1: Have we answered the
question about whether config context needs addressing at core level for
delegated Uis?

GeneralDialogs.5: Chaining of dialogs
is presumably out of scope. Have we agreed as a TC which use cases are
in scope & out of scope?

Discovery.3: Would we want to say that
if a client makes a GET request with the Prefer header, and the resource
being requested is a Container of Containers, that the child containers
have their dialog descriptors included incline? (If PreferMinimalContainer
was not specified).

Creation.4: This use case has been included
in Automation 2.1 at open-services.net, called "Deferred-Execution
Creation Dialogs" (but we called the general idea "Template Dialogs"
in discussion whilst we were drafting). Automation 3.0 (if it ever happens)
could define a new Link header rel URI for template dialogs, but would
we want that in core? (Template dialogs are a special kind of creation
dialog where the created resource has a short expected lifetime, the same
as a prefilled dialog URI.)

Selection.2: See comment above about
combined creation/selection dialogs.

Editor/StateTransition.3: OSLC Actions
2.0 defined an "ActionDialog", which could achieve the state
transition use case: http://open-services.net/wiki/core/Actions-2.0/#pattern-immed-dialog,
but discovery of that could possibly be quite different to discovery of
creation & selection dialogs, so that could be left until we look at
OSLC Actions 3.0 (if ever). Just FYI.



Martin

<oslc-core@lists.oasis-open.org> wrote on 19/02/2015
22:29:47:

> From: Samuel Padgett <spadgett@us.ibm.com>
> To: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 19/02/2015 22:29
> Subject: [oslc-core] Delegated Dialogs 3.0 Ready
for Review
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> As discussed in today's Core TC call, the dialogs draft is ready for
> review. I'd appreciate any feedback you have. Please try to get me
> any comments by March 5, so I can prepare the document for public
review.
> 
> http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/
> specs/dialogs-v3.html
> 
> Thanks,
> -- 
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC
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