case sensitive return type

[Richard S Hendershot <rh...@isterra.com>]

is it possible to make the return type Upper case?

<return xsi:type="ns1:OrderID"> <orderID
xsi:type="xsd:string">123456789A</orderID> </return>

..where I would like 'OrderID' to reflect the return object type as well as
the runtime value?  Like so:
<return xsi:type="ns1:OrderID"> <OrderID
xsi:type="xsd:string">123456789A</OrderID> </return>

I'm using BeanSerializer and mapping:
...Constants.NS_URI_SOAP_ENC, new QName("[snip]","OrderID")...

It's working, ok, but is not quite to the specification I was given for our
application.


Thanks in Advance!
-rsh


-----Original Message-----
From: Martin Gudgin [mailto:marting@develop.com]
Sent: Thursday, June 07, 2001 9:41 AM
To: soap-dev@xml.apache.org
Subject: XML Protocol: Proposals to address SOAPAction header


The W3C XML Protocol Working Group is attempting to address perceived and
reported problems with the "SOAPAction" mechanism in the HTTP binding ( see
SOAP 1.1 Section 6.1.1 [1] ). As part of this process, the WG wishes to
solicit
comments and guidance on two proposals it has generated, as below.

Comments must go to xmlp-comments@w3.org by 2001-06-18, and should address
the proposals as they sit, and may optionally make general comments on
resolution of issues with SOAPAction. Those representing the positions of
particular groups or organizations are requested to clearly identify
themselves as such. The WG encourages additional discussion on the
xml-dist-app@w3.org
mailing list.

Neither of the following options precludes equivalent functionality
elsewhere.

Proposal A:
Use of SOAPAction is discouraged.  SOAPAction is an optional part of XMLP,
supported but not required.  Services MAY require SOAPAction and any
software wishing to access those services MUST be able to send it.

Proposal  B:
Use of SOAPAction is deprecated.  Senders SHOULD NOT send SOAPAction.
Receivers MUST NOT accept or reject messages on the basis of the presence,
absence, or value of the SOAPAction header.

Regards

Martin Gudgin
For the W3C XML Protocol Working Group

[1] http://www.w3.org/TR/SOAP/#_Toc478383528

RE: case sensitive return type

["Matthew J. Duftler" <du...@watson.ibm.com>]

Hi Richard,

The BeanSerializer uses the property name as the element name. One solution
to your problem would be to specify your own BeanInfo class. That BeanInfo
could return whatever property names you want.

Thanks,
-Matt

> -----Original Message-----
> From: Richard S Hendershot [mailto:rhendershot@isterra.com]
> Sent: Thursday, June 07, 2001 5:22 PM
> To: soap-dev@xml.apache.org
> Subject: case sensitive return type
>
>
>
> is it possible to make the return type Upper case?
>
> <return xsi:type="ns1:OrderID"> <orderID
> xsi:type="xsd:string">123456789A</orderID> </return>
>
> ..where I would like 'OrderID' to reflect the return object type
> as well as
> the runtime value?  Like so:
> <return xsi:type="ns1:OrderID"> <OrderID
> xsi:type="xsd:string">123456789A</OrderID> </return>
>
> I'm using BeanSerializer and mapping:
> ...Constants.NS_URI_SOAP_ENC, new QName("[snip]","OrderID")...
>
> It's working, ok, but is not quite to the specification I was
> given for our
> application.
>
>
> Thanks in Advance!
> -rsh
>
>
> -----Original Message-----
> From: Martin Gudgin [mailto:marting@develop.com]
> Sent: Thursday, June 07, 2001 9:41 AM
> To: soap-dev@xml.apache.org
> Subject: XML Protocol: Proposals to address SOAPAction header
>
>
> The W3C XML Protocol Working Group is attempting to address perceived and
> reported problems with the "SOAPAction" mechanism in the HTTP
> binding ( see
> SOAP 1.1 Section 6.1.1 [1] ). As part of this process, the WG wishes to
> solicit
> comments and guidance on two proposals it has generated, as below.
>
> Comments must go to xmlp-comments@w3.org by 2001-06-18, and should address
> the proposals as they sit, and may optionally make general comments on
> resolution of issues with SOAPAction. Those representing the positions of
> particular groups or organizations are requested to clearly identify
> themselves as such. The WG encourages additional discussion on the
> xml-dist-app@w3.org
> mailing list.
>
> Neither of the following options precludes equivalent functionality
> elsewhere.
>
> Proposal A:
> Use of SOAPAction is discouraged.  SOAPAction is an optional part of XMLP,
> supported but not required.  Services MAY require SOAPAction and any
> software wishing to access those services MUST be able to send it.
>
> Proposal  B:
> Use of SOAPAction is deprecated.  Senders SHOULD NOT send SOAPAction.
> Receivers MUST NOT accept or reject messages on the basis of the presence,
> absence, or value of the SOAPAction header.
>
> Regards
>
> Martin Gudgin
> For the W3C XML Protocol Working Group
>
> [1] http://www.w3.org/TR/SOAP/#_Toc478383528
>
>
>
>
>
>
>
>