You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Simon Oldham <em...@simonoldham.com> on 2008/08/27 16:20:45 UTC
Axis elements
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
Re: Axis elements
Posted by Simon Oldham <em...@simonoldham.com>.
Hi Anne,
I came across that very link (I substituted Person for Bananas in my
example).
That is some interesting information you have found. That is exactly what I
hoped to find out - the reason behind the adoption of multiRef as the
accessor name.
Thanks very much for clearing that up. It has been bugging me for days.
Cheers,
Simon
On Thu, Aug 28, 2008 at 1:06 PM, Anne Thomas Manes <at...@gmail.com>wrote:
> 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 <at...@gmail.com>
> 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 <em...@simonoldham.com>
> 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 <at...@gmail.com>
> >> 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 <em...@simonoldham.com>
> >>> 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: axis-user-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
Re: Axis elements
Posted by Anne Thomas Manes <at...@gmail.com>.
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 <at...@gmail.com> 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 <em...@simonoldham.com> 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 <at...@gmail.com>
>> 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 <em...@simonoldham.com>
>>> 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: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis elements
Posted by Anne Thomas Manes <at...@gmail.com>.
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 <em...@simonoldham.com> 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 <at...@gmail.com>
> 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 <em...@simonoldham.com>
>> 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: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Axis elements
Posted by Simon Oldham <em...@simonoldham.com>.
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 <at...@gmail.com>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 <em...@simonoldham.com>
> 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
Re: Axis elements
Posted by Anne Thomas Manes <at...@gmail.com>.
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 <em...@simonoldham.com> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org