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: Re: [oslc-core] Delegated Dialogs 3.0 Ready for Review

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


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

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