Re: Position on issue 194

 Noah, 
 I think your summary is correct.
 I have comments on the disadvantages below.
 One more thing: I can see RPC being in SOAP because SOAP will 
often be used for something like RPC. I can see the Data Model 
(and Encoding) in SOAP because it's very useful for RPC. On the 
other hand I don't see how SOAP is different from general XML 
(SOAP carries almost general XML) in its need of marking data 
encodings.
 I'd rather see something like xml:encodingStyle (same level as
xml:lang, xml:base etc.) that would apply to any XML document.

 But wait, XML already solves this with namespaces, I think. In 
fact, it is our problem that the Encoding is not in a fixed 
namespace - that would be the solution. Why do we need QNames as 
edge labels anyway? 8-)

 It's a great pity I didn't think of this much earlier when 
something could still have been done about this.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 30 Apr 2002 noah_mendelsohn@us.ibm.com wrote:

 > Jacek:
 > 
 > I am neither agreeing nor disagreeing, but I want to make sure that I 
 > understand your proposal.  The believe that what you're saying is: "SOAP 
 > already requires that you understand the correct interpretation of any 
 > header or body block that you process.  If you understand that, then you 
 > will surely know whether the block is to be interpreted as encoded, and if 
 > so how."
 > 
 > If I have correctly understood you, then I think the proposal stacks up 
 > this way:
 > 
 > Advantages of scrapping encodingStyle:
 > * Oe less mechanism to describe, implement, and test
 > * The semantics were not clear, and there were a number of edge 
 > conditions.  By leaving out the mechanism, we avoid the need to worry 
 > about any of that.
 > 
 > Disadvantages:
 > * With SOAP 1.1 is possible to write generalized middleware that decodes 
 > graphs without knowing anything about the QNames or definitions of 
 > particular header and body elements.  With your proposal, it would be 
 > necessary to make each implementation aware (one way or another) of which 
 > things were to be encoded, and which not.

What kind of graphs? What is a graph? Why does a data model and
an encoding thereof need to have graphs? The only cases I see we
lose are:
 1) An application can handle multiple encodings of one data 
model. My question is - why are there multiple encodings of one 
data model? What is the benefit of that?
 2) An application can map a set of data models into its own 
internal data model which it then works with. This is a real, 
although IMO minor case.
 3) An application can handle multiple (more than in case 2) data
models in the same way, not necessarily knowing which is which.
Here I believe the most practical approach would be to work on
the XML level because otherwise we're back to the case 2.

 > * The messages become somewhat less self describing.
 > * We lose a level of cross checking. 

These I agree with, although you didn't state the first one
separately.

Jacek

Received on Tuesday, 30 April 2002 16:35:17 UTC