Re: [oslc-core] Delegation Dialog issues

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

> 3. Dialog message protocols

> OSLC2 supported postMessage and windowName protocols for interaction
between delegated dialogs and the client window in which they are hosted
in order for the dialog to communicate the selection or creation results
back to the client application. 

> Resolution: I think we can safely assume that modern browsers now
support HTML5 postMessage and can drop the windowName protocol. 

MP: I hate to suggest it,
but if our compatibility statement is that OSLC 2.0 clients need to work
with OSLC 3.0 servers, and some 2.0 clients might expect servers to implement
the window name protocol, don't we need to continue to require servers
support it? At the same MAY/SHOULD/MUST level as 2.0?

Kind regards,

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel

Phone: +44 (0)1962 815317 | Tie-Line: 37245317 E-mail: martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited Registered in
England and Wales with number 741598 Registered office: PO Box 41, North
Harbour, Portsmouth, Hants. PO6 3AU 



From:      
 "Jim Amsden"
<jamsden@us.ibm.com>
To:      
 "OASIS OSLC Core
TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
Date:      
 22/07/2015 22:04
Subject:    
   [oslc-core]
Delegation Dialog issues
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

Not much here.

1. Delegated Dialog Discovery

OSLC2 uses an oslc:selectionDialog of an oslc:Service resource that has
an inlined oslc:Dialog element that has an oslc:dialog property whose value
is the URI of the selection dialog. Similar for creationDialog. OSLC3 uses
Link and Prefer headers on an LDPC to get similar information. 2.0/3.0
Discovery compatibility re-introduces the ServiceProviderCatalog, ServiceProvider
and Service resources with the properties referenced in dialog discovery.
So these just need to be summarized and reference in the delegated dialog
specification. This provides 3 ways to get the delegated dialog in OSLC3.



2. Dialog Prefill

For dialog prefill, neither OSLC2 or OSLC3 specifies specifically what
formats are required for the entity request body that contains the representation
of the resource the server should use to prefill the dialog. We can assume
its the same resource representations and media-types that a client could
GET on the created resource. That's addressed in the core overview document
in resource representations, but could be mentioned in the dialog prefill
section too.

3. Dialog message protocols

OSLC2 supported postMessage and windowName protocols for interaction between
delegated dialogs and the client window in which they are hosted in order
for the dialog to communicate the selection or creation results back to
the client application. 

Resolution: I think we can safely assume that modern browsers now support
HTML5 postMessage and can drop the windowName protocol. 

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575


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