SOAP encoding processors look for a local name "multiRef", so if you used "bananas" instead, the SOAP processor might not be able to process the message.
When using use="literal", the message must conform exactly to the schema that described the message. If you insert an unexpected element, or you change an element's QName, you'll receive an "unexpected element" message or something similar. When using use="encoded", the message must contain semantically equivalent information, but the syntax does not necessarily correspond exactly to the schema. SOAP encoding uses a data model rather than the schema to serialize and deserialize the message. SOAP encoding was designed to enable the efficient serialization of object graphs. For example, if you have an element value that appears more than once in the message, SOAP encoding will replace the element with a multiRef. Anne On Thu, Aug 28, 2008 at 6:59 AM, Simon Oldham <[EMAIL PROTECTED]> wrote: > Hi Anne, > > Thanks for your response. I have poured through the specification many times > now. I think it is the name of the accessor "multiRef" that confused me. > However, I think I now understand but if you could confirm this I would be > grateful. > > My understanding is now that the name multi-reference accessor is > irrelevant, it is the type that is important? > > So whilst Axis might generate: > > <multiRef id="id1" soapenc:root="0" > > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > xsi:type="xsd:int" > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";> > 2 > </multiRef> > > It would also be perfectly legal to change the accessor name to, say, > "bananas" and generate > > <bananas id="id1" soapenc:root="0" > > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > xsi:type="xsd:int" > xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";> > 2 > </bananas> > > Obviously, I wouldn't do that but, theoretically, is that legal? > > Do I understand correctly now? > > Thanks, > > Simon > > > On Wed, Aug 27, 2008 at 11:09 PM, Anne Thomas Manes <[EMAIL PROTECTED]> > wrote: >> >> The use of multiple references is defined in "The rules for >> serialization" in Section 5.1 [1] of the SOAP 1.1 spec: >> >> The rules for serialization are as follows: >> >> 1. All values are represented as element content. A multi-reference >> value MUST be represented as the content of an independent element. A >> single-reference value SHOULD not be (but MAY be). >> 2. For each element containing a value, the type of the value MUST >> be represented by at least one of the following conditions: (a) the >> containing element instance contains an xsi:type attribute, (b) the >> containing element instance is itself contained within an element >> containing a (possibly defaulted) SOAP-ENC:arrayType attribute or (c) >> or the name of the element bears a definite relation to the type, that >> type then determinable from a schema. >> 3. A simple value is represented as character data, that is, >> without any subelements. Every simple value must have a type that is >> either listed in the XML Schemas Specification, part 2 [11] or whose >> source type is listed therein (see also section 5.2). >> 4. A Compound Value is encoded as a sequence of elements, each >> accessor represented by an embedded element whose name corresponds to >> the name of the accessor. Accessors whose names are local to their >> containing types have unqualified element names; all others have >> qualified names (see also section 5.4). >> 5. A multi-reference simple or compound value is encoded as an >> independent element containing a local, unqualified attribute named >> "id" and of type "ID" per the XML Specification [7]. Each accessor to >> this value is an empty element having a local, unqualified attribute >> named "href" and of type "uri-reference" per the XML Schema >> Specification [11], with a "href" attribute value of a URI fragment >> identifier referencing the corresponding independent element. >> 6. Strings and byte arrays are represented as multi-reference >> simple types, but special rules allow them to be represented >> efficiently for common cases (see also section 5.2.1 and 5.2.3). An >> accessor to a string or byte-array value MAY have an attribute named >> "id" and of type "ID" per the XML Specification [7]. If so, all other >> accessors to the same value are encoded as empty elements having a >> local, unqualified attribute named "href" and of type "uri-reference" >> per the XML Schema Specification [11], with a "href" attribute value >> of a URI fragment identifier referencing the single element containing >> the value. >> 7. It is permissible to encode several references to a value as >> though these were references to several distinct values, but only when >> from context it is known that the meaning of the XML instance is >> unaltered. >> 8. Arrays are compound values (see also section 5.4.2). SOAP arrays >> are defined as having a type of "SOAP-ENC:Array" or a type derived >> there from. >> >> [1] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383513 >> >> Anne >> >> On Wed, Aug 27, 2008 at 10:20 AM, Simon Oldham <[EMAIL PROTECTED]> >> wrote: >> > Hi, >> > >> > I had an issue on a project recently with Apache Axis sending Multi >> > Reference values to a JWSDP 1.1 Web Service. The problem was solved by >> > advising the client to turn off multiRefs in Axis. (I know RPC/Encoded >> > is >> > deprecated but this is legacy tech). >> > >> > Anyway, this incident got me curious and investigating what these >> > "multirefs" were. I can see from reading the SOAP 1.1 spec that they >> > fall >> > under the (now deprecated) Section 5 Encoding. >> > >> > However, one thing still puzzles me when Googling on this subject and >> > that >> > is the existence of a "multiRef" element in SOAP responses - I believe >> > they >> > would be referred to as "property accessors"? Are these purely an Apache >> > Axis invention (I certainly can't find any trace of them in the SOAP >> > spec) >> > and, if so, why (given that they are not in the SOAP specification)? >> > >> > If somebody could explain this in detail I would very grateful as I am >> > the >> > type of guy that can't rest until I fully understand something. :-) >> > >> > Thanks in advance, >> > >> > Si >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
