Simon, I did a bit more research on this question.
The first SOAP engine, IBM's SOAP4J used the "multiRef" local name. IBM contributed this project to Apache, and it became Apache SOAP. Axis is a follow-on project to Apache SOAP. Although it is a complete rewrite with a different architecture, it maintained the use of the "multiRef" local name. Other SOAP engines do not necessarily use the same local name. I found this posting that indicates that .NET uses a more descriptive local name for the referenced element (in this case, "Person"): http://www.developerfusion.co.uk/show/4694/3/ Anne On Thu, Aug 28, 2008 at 7:37 AM, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > 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]