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]
