SOAP issue on the use of root attribute

FYI - this was brought up as an issue on the soapbuilders list. I
forward it to this list as I would like to add it as an issue in [2].

Henrik 

[1] http://groups.yahoo.com/group/soapbuilders/message/1909?threaded=1
[2] http://www.w3.org/2000/xp/group/xmlp-issues

-----Original Message-----
From: Simon Fell [mailto:sfell@streetfusion.com] 
Sent: Tuesday, April 17, 2001 10:09
To: 'soapbuilders@yahoogroups.com'
Subject: RE: [soapbuilders] Request For Clarification


sounds good to me, it will need to be clear that this promotes the MAY
in section 5 re root attribute to a REQUIRED when working in conjunction
with section 7.

Thanks
Simon

-----Original Message-----
From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
Sent: Tuesday, April 17, 2001 9:52 AM
To: soapbuilders@yahoogroups.com
Subject: RE: [soapbuilders] Request For Clarification



I agree that the wording in section 5.6 [1] is somewhat cryptic but the
gist is indeed to be able to solve the problem at hand. If the case is
that it does then I agree that 4 is a viable way to go.

Note that section 5 is inherently independent of the RPC convention in
section 7 and so there is no guarantee based on section 5 alone that the
serialization root is the method call or a method response.

What I think needs clarification is in section 7.1 [2] where it should
say that the request as well as the response must be serialized as the
root object of the graph if encoded according to section 5.

Does this make sense?

Henrik

[1] http://www.w3.org/TR/SOAP/#_Toc478383501
[2] http://www.w3.org/TR/SOAP/#_Toc478383533

>4 gets my vote, although the root attribute is not required,
>which makes things tricky, it needs some way to fall back to 
>being able to determine the name of the request/response 
>struct via some external means (such as WSDL and/or being told 
>it by the client code)
>
>Section 5 seems overly flexible to me, and i don't see what
>use that flexibility is in some cases. I hope that for XMLP 
>the flexibility is reduced, or at least there are some good 
>examples of why the flexibility is needed.
>
>1 is not an option for anyone seriously aiming to provide a
>complete section 5 solution, and 3 looks interesting, but a 
>political nightmare.
>
>Cheers
>Simon
>
>On Tue, 17 Apr 2001 08:01:41 -0700, in soap you wrote:
>
>>So, there appear to be four different options:
>>
>>1.    Not solve the problem at all.  If any implementation 
>ever serializes a
>>multi-reference value as part of a method invocation or response the
>>results will be unpredictable.
>>
>>2.    Everyone implements WSDL.
>>
>>3.    Everyone picks either pre-order or post-order serialization and
>>deserialization and then we invent a new encodingStyle value which
>>everyone recognizes.
>>
>>4.    Everyone implements the SOAP-ENC:root attribute 
>described in the SOAP
>>1.1 specification.
>>
>>Have I missed any?
>>
>>By the way, I note that post-order serialization increases the number
>>of fixups that need to occur on deserialization and so slows down 
>>and/or complicates deserialization code.  I also note that any 
>>implementation is within its rights to choose number 4, since that is 
>>in the spec.
>>
>>What do you suggest?



To unsubscribe from this group, send an email to:
soapbuilders-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Do you have 128-bit SSL encryption server security? Get VeriSign's FREE
Guide, "Securing Your Web Site for Business." Get it now!
http://us.click.yahoo.com/EVNB7A/c.WCAA/bT0EAA/WNqXlB/TM
---------------------------------------------------------------------_->

To unsubscribe from this group, send an email to:
soapbuilders-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Received on Tuesday, 17 April 2001 13:27:11 UTC