[wsf-dev] FW: LAP-Tech: Making ID-WSF 1.x era service specifications work over ID-WSF 2.0

Eric Tiffany eric at projectliberty.org
Thu Jan 3 08:32:18 PST 2008


Here is a message from Greg regarding issues discussed on today's call.  I
couldn't find the original message, but here is conor's reply agreeing with
Greg.

ET
-- 
____________________________________________________
Eric  Tiffany             |  eric at projectliberty.org
Interop Tech  Lead        |  +1 413-458-3743
Liberty Alliance          |  +1 413-627-1778 mobile


------ Forwarded Message
From: "Cahill, Conor P" <conor.p.cahill at intel.com>
Date: Sat, 7 Oct 2006 16:08:47 -0700
To: Greg Whitehead <greg.whitehead at hp.com>, LibertyTech
<technology at projectliberty.org>
Conversation: LAP-Tech:  Making ID-WSF 1.x era service specifications work
over ID-WSF 2.0
Subject: RE: LAP-Tech:  Making ID-WSF 1.x era service specifications work
over ID-WSF 2.0


This looks good to me.  Perhaps with an example as well.

Conor 

> -----Original Message-----
> From: technology-owner at projectliberty.org
> [mailto:technology-owner at projectliberty.org] On Behalf Of
> Greg Whitehead
> Sent: Saturday, October 07, 2006 12:31 PM
> To: LibertyTech
> Subject: LAP-Tech: Making ID-WSF 1.x era service
> specifications work over ID-WSF 2.0
> 
> I propose the following convention for making ID-WSF 1.x era
> service specifications work over ID-WSF 2.0, without
> requiring any changes to the specifications themselves. This
> should allow any existing ID-WSF 1.x specification, such as
> PP or EP, to be used in the ID-WSF 2.0 world.
> 
> This would have been good to include in the cross framework
> interoperability document. Maybe it can go in a future version.
> 
> 1) ResourceID
> 
> When constructing messages according to the service
> specification, use urn:liberty:isf:implied-resource for the
> ResourceID. In the case that the service specification makes
> ResourceID optional, and defaults to
> urn:liberty:isf:implied-resource, then the ResourceID element
> should be omitted.
> 
> 2) Action URIs
> 
> For each message defined by the service specification,
> construct the action URI for that message by taking the
> namespace qualified name of the message element (i.e. the
> element that will be placed in the SOAP Body) and
> concatenating the namespace with the element name, separated by ':'.
> 
> So, for example, for the PP service the action URIs would be:
> 
> urn:liberty:id-sis-pp:2003-08:Query
> urn:liberty:id-sis-pp:2003-08:QueryResponse
> urn:liberty:id-sis-pp:2003-08:Modify
> urn:liberty:id-sis-pp:2003-08:ModifyResponse
> 
> NOTE: I believe this simple scheme works for both URN and URL
> based namespace URIs.
> 
> 
> -Greg
> 
> Liberty Alliance Confidential
> 
> The contents of this message are considered confidential to
> the Liberty Alliance per the Membership Agreement and should
> not be shared outside of the Alliance unless otherwise noted
> in the body of this email by the original sender.
> ______________________________
> 
> To unsubscribe from this list, login to the Project Liberty
> Members Area, edit your profile  and unsubscribe yourself
> from technology at projectliberty.org.
> ______________________________
> 
> 
> 
> 
> 
Liberty Alliance Confidential

The contents of this message are considered confidential to the Liberty
Alliance per the Membership Agreement and should not be shared outside of
the Alliance unless otherwise noted in the body of this email by the
original sender.
______________________________

To unsubscribe from this list, login to the
Project Liberty Members Area, edit your profile  and unsubscribe yourself
from technology at projectliberty.org.
______________________________







------ End of Forwarded Message





More information about the Wsf-dev mailing list