Re: SOAP Encoding - Arrays

 Simon, my replies are below. 8-)

                   Jacek Kopecky

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



 > I have a few comments,
 > 1) Part 1 contains a specific point that the normative schemas are
 > available by de-referencing the namespace URI's. I didn't see this
 > stated in Part 2

This should be a small editorial issue, I hope the editors notice 
your message. 8-)

 > 2) section 3.1 no longer mentions that multi-ref elements should be
 > serialized at the top level of serialization [and IIRC, i thought this
 > had been dropped, and they could all be inlined], but the examples in
 > section 3.5.1, still show independent roots

Again an editorial issue, and I think that Marc Hadley is working 
on the examples now.

 > 3) I thought that the definition of base64Binary in XSD removed the
 > requirement for the enc:base64 ?

Probably so, yes.

 > 4) If the array item element name is not significant, might it be
 > better to give it a specific name [as has been done with the return
 > parameter in the RPC part]. ?

 In RPC return parameter the problem was that it has to be 
distinguishable in the return struct. In struct you distinguish 
by names, therefore we had to give it a fixed name.
 On the other hand, if we picked a name for the array members, 
you would lose the ability to use enc:int, enc:float etc. to 
signify the type in an element's name. (BTW, I don't see this 
ability as a very important one, but it's already there and I 
don't see a big issue with it.)

 > 5) in 3.1 rule 2, item 2 it says "the containing element instance is
 > itself contained within an element containing a (possibly defaulted)
 > enc:itemType attribute, " however part 1 rules out defaulted
 > attributes.

 Part 1 rules out defaulted attributes for the attributes it 
specifies, i.e. actor and mustUnderstand and encodingStyle, I 
think. IMO Encoding can allow defaulted attributes because it is 
an extension of SOAP. I doubt SOAP can forbid every extension and 
application to use defaulted attributes.

 > 6) itemType seems redundant, everything it can do, can already be
 > achieved via schema types / xsi:type usage

 In fact, itemType can be helpful if you don't use a schema and 
you receive an array and you want to start deserializing it, 
especially if the array members are polymorph - it would be 
necessary to read the whole XML representation of the array in 
memory before you knew the supertype of the array members. BTW, 
use of itemType is optional. 8-)

 > 7) concreteSize is defined as
 > 	concreteSize    ::=    positive integer 
 > but positive integer doesn't appear to be defined, I assume positive
 > integer includes 0 ?

Positive integer is defined in schemas and it does not include 0. 
But your point is that in this case you cannot pass an array with 
one of the dimensions zero (and therefore with no members). Most 
notably an empty one-dimensional array is the usecase, but this 
can be represented with arraySize="*" or no arraySize attribute 
at all.

I'll post an other email starting discussion on this, please 
don't reply to this issue (no. 7) in this thread.

Jacek

Received on Tuesday, 5 February 2002 05:08:10 UTC