Re: [oslc-core] Delegation Dialog issues

Agree it needs to be retained at the same
level as OSLC2. 

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

From:      
 Martin P Pain <>
To:      
 Jim Amsden/Raleigh/IBM@IBMUS
Cc:      
 "OASIS OSLC Core
TC Discussion List ()" <>
Date:      
 07/23/2015 08:32 AM
Subject:    
   Re: [oslc-core]
Delegation Dialog issues
Sent by:    
   <>

> 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: 
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" <> 
To:        "OASIS
OSLC Core TC Discussion List ()" <>
Date:        22/07/2015
22:04 
Subject:        [oslc-core]
Delegation Dialog issues 
Sent by:        <>

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