Re: Position on issue 194

 Ray, 
 I know you disagree, and the disagreement stems from the fact 
that the attribute is not well specified - one can understand it 
in a couple different ways. I always uderstood it as specifying 
the encoding for its bearer element and the children thereof 
(unless they specified their own encoding).
 I also know that you use it, that's why I said that it's not 
widely employed as opposed to saying that it's not used at all. 
Don't take this as me flouting your implementation, it's just 
that from my point of view encodingStyle is really not employed 
widely. For example even sparse arrays were used in some 
applications and we removed them nevertheless.
 As for the hole in SOAP 1.2 if encodingStyle attribute was
removed, I respectfully disagree here, too. If need be - if an
encoding expects to contain other encodings inside - it is my 
opinion that the outer encoding should handle the situation 
itself.
 You see, even with SOAP Encoding, the meaning of an inner change 
of encodingStyle is debatable - does it apply to the whole 
element (in SOAP Data Model that would be the edge *and* the 
value) or only to the value? Answering "the whole element" raises 
the question of what the element is then in SOAP Data Model - 
there is no edge there from the parent element. Answering "the 
value only" introduces a SOAP Data Model term into SOAP core.

 It is our responsibility to allow carrying arbitrary data in 
SOAP envelopes and we do that - you can carry (almost) arbitrary 
XML data in there. It is our responsibility to provide a graph 
data model (or something alike, I don't remember the wording) and 
we do that. It is our responsibility to provide RPC and we do 
that. Nowhere in the requirements or in the charter (please 
correct me if I'm wrong) do I see the need for explicit 
encodingStyle.
 SOAP Encoding (and Data Model) in fact IMHO don't allow any 
other encoding inside, defining compound types and terminals - 
which of these encompasses the data in changed encodings?
 So I believe SOAP 1.2 wouldn't lose much by dropping
encodingStyle and it would gain simplicity and clarity (by
removing complexity and undefined cases).
 Best regards,

                   Jacek Kopecky

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



On Tue, 30 Apr 2002, Ray Whitmer wrote:

 > I feel the discussion has not been sufficient on the merits of the 
 > attribute.
 > 
 > Jacek Kopecky wrote:
 > 
 > > Hi all, since I won't be able to attend the following two 
 > >telcons, I'd like to state my position on one of the remaining 
 > >two issues - 194 - encodingStyle attribute on Envelope, Header.
 > > I believe that the attribute has no meaning on Envelope and 
 > >Header and that using it there is wrong (although I recognize 
 > >it's currently being used in this way).
 > >
 > I disagree with this position, as I have stated before.  The attribute 
 > has a meaning on envelope, header, and body, in each case specifying the 
 > default encoding of blocks contained within.
 > 
 > The meaning on headers is the same as the meaning on blocks within body. 
 >  They are all blocks, and it is unclear why it would not be so.
 > 
 > We actively use it this way in SOAP 1.1, and feel that the specification 
 > calls for it to be used this way.
 > 
 > >I think the spec needs to be changed at least to remove the 
 > >inconsistency between prose and schema.
 > > There has been a proposal by Henrik [1] to remove the attribute 
 > >altogether and I support this course because encodingStyle is not 
 > >widely employed (it's mentioned in messages and it may be checked 
 > >for, but it's not widely used to do meaningful stuff), it is 
 > >underspecified (What is a data encoding anyway? What can it do to 
 > >the message? What is the meaning of changing encodingStyle in the 
 > >middle of the XML tree? Where does encodingStyle apply?) and at 
 > >least in some implementations (including Systinet's WASP) it 
 > >isn't necessary for proper functioning.
 > > We have already reduced the attribute from being a list of URIs
 > >to a single URI for some similar reasons (see issues 159 [2] and
 > >166 [3]).
 > > Best regards,
 > >
 > There would be a hole if the 1.2 specification were modified as proposed.
 > 
 > Ray Whitmer
 > rayw@netscape.com
 > 
 >

Received on Tuesday, 30 April 2002 15:02:06 UTC