OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: RE: [ws-caf] [Bug 134] New: mustUnderstand needs moving and defining


W3c Web service architecture defines web services as SOAP+WSDL. 
I see no reason to adopt a different definition.

Martin.

>-----Original Message-----
>From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] 
>Sent: 04 June 2004 13:46
>To: ws-caf@lists.oasis-open.org
>Subject: RE: [ws-caf] [Bug 134] New: mustUnderstand needs 
>moving and defining
>
>
>I have already advocated the dropping of mustPropagate. 
>
>If we can assume SOAP headers then mustUnderstand is a 
>property of the header.
>
>The conclusion would then be: there is no role for WS-Context 
>as a base class reflecting these two relationship attributes.
>
>* * *
>
>However, to be stringent: can we assume SOAP headers? WSDL is 
>our starting point: presumably at some point (in a future 
>fully-specified, architecturally-articulate world) our WSDL 
>message parts can map to unknown encodings and unknown 
>transfer protocols. 
>
>Therefore, if we are to state: "this context must be 
>understood" then there must be a way of doing that without 
>relying on the SOAP header. (As you may guess, I'd love to be 
>argued out of that conclusion!)
>
>This would indicate that WS-Context contexts, viewed as a base 
>class, contain a must understand element.
>
>It would also indicate that there must be a "did not 
>understand" fault, defined by WS-Context. 
>
>What do other TC members think? I have had great trouble 
>trying to find a coherent general statement on how to create a 
>WSDL binding that maps to any arbitrary encoding and any 
>underlying protocol. It seems that there are strong practical, 
>tools-based assumptions, which are not properly codified.
>
>Do we define Web Services as SOAP+WSDL, or just WSDL, in other words?
>
>Alastair
>
>-----Original Message-----
>From: bugzilla-daemon@arjuna.com [mailto:bugzilla-daemon@arjuna.com] 
>Sent: 30 May 2004 17:45
>To: ws-caf@lists.oasis-open.org
>Subject: [ws-caf] [Bug 134] New: mustUnderstand needs moving 
>and defining
>
>http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=134
>
>           Summary: mustUnderstand needs moving and defining
>           Product: WS-Context
>           Version: 1.0
>          Platform: PC
>        OS/Version: Windows 2000
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: Text and diagrams
>        AssignedTo: ws-caf@lists.oasis-open.org
>        ReportedBy: peter.furniss@choreology.com
>         QAContact: mark.little@arjuna.com
>
>
>the mustUnderstand and mustPropagate attributes should be 
>moved to context and 
>don't belong on the service list.
>
>Since a context is (commonly) a soap header, the 
>SOAP:mustUnderstand attribute 
>is available, and mustUnderstand could be considered superfluous.
>
>However, the SOAP:mustUnderstand attribute could be 
>interpreted as meaning the 
>ws-context-specified aspects must be understood, and the 
>wsctx:mustUnderstand 
>means the context type must be understood. Thus 
>SOAP:mustUnderstand="1" 
>wsctx:mustUnderstand="0" wsctx:mustPropagate="1" would mean 
>the receiver was 
>guaranteed to propagate the context unchanged if it did not 
>recognise the 
>context type (or through a soap fault). (if it did recognise 
>the context type, 
>it could sort out the propagation for itself)
>
>This latter approach seems to add necessary functionality to 
>support the
>two-
>level function identification of ws-context (context namespace 
>of whole header; 
>context type as particular protocol). It may be better to rename 
>wsctx:mustUnderstand to avoid (human) confusion with the SOAP 
>attribute.
>
>
>
>------- You are receiving this mail because: -------
>You are the assignee for the bug, or are watching the assignee.
>



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