Thanks for joining us on our telecon. It was a good call. You've shown us that JAX-RPC does, indeed, define the rules Glen presented below. And I'm happy to hear that you plan to make them more explicit in the maintenance release of JAX-RPC. All that's left, then, is for me to point out the TCK WSDL files that don't follow these rules; specifically, rule #3.
jaxrpc/ee/w2j/document/literal/marshalltest/MarshallTest.wsdl
jaxrpc/ee/w2j/document/literal/simpletest/SimpleTest.wsdl
jaxrpc/ee/w2j/document/literal/stockquote/stockquote.wsdl/.xsd
Another clarification that I'd like to see in the spec. MarshallTest.wsdl and SimpleTest.wsdl use the same element in both the input and the output messages. For example, SimpleTest.wsdl's input and output messages both point to "StringName" which contains an element named "inputString". Since there is an input parameter called "inputString" AND an output parameter called "inputString", one COULD assume that the method should look like:
public void echoString(StringHolder inputString);
AXIS actually does this right now. But I think this is wrong. It SHOULD look like:
public String echoString(String inputString);
The determination of whether to use a holder is based on PART name, not PARAMETER name. It says that in section 4.3.4, but a comment to this effect in section 6 somewhere would also be helpful.
AXIS folks, I'll look into fixing this when I get the chance (unless you want to, Tom, since you wrote the wrapped code to begin with). Even if the TCK folks change the wsdl as we hope, we'll still fail these tests until we fix this.
Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: "'Rahul Sharma'" <[EMAIL PROTECTED]>
Subject: RE: JAX-RPC TCK and wrapped doc/lit
As a bit of further context to this discussion, we came up with the following set of rules for when to consider an operation "wrapped" (and therefore appropriate for stripping off the outer element and using the inner ones as the parameters in the SEI):
�
1) There is a single message <part>
2) The <part> is defined with element="" as opposed to type="" (literal)
3) The element QName matches the <operation> QName (this might actually only mean that the local parts match - not positive)
4) There are NO attribute declarations on the referenced <element> (if there were, we would need a well-defined way to alter the SEI to account for those values)
�
In our opinion, if an operation does not match these rules, we should not "wrap" it.
�
Thanks,
--Glen
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 17, 2002 9:23 AM
To: [EMAIL PROTECTED]
Cc: Rahul Sharma
Subject: Re: JAX-RPC TCK and wrapped doc/lit
Rahul, to prime our discussion today I thought I'd outline our current position. (I realize you may not see this note before the telecon. If not, I'll go over it when we start.) I had presented 3 issues we have with doc/lit and the TCK:
1. The example from the TCK shown below does not follow the example in the spec. In the JAX-RPC example (and in .NET) the element name is the
same as the operation name; in the TCK it is not.
2. JAX-RPC section 6.4.3 shows TWO possible Java mappings for the given WSDL. Therefore the TCK cannot mandate one.
3. We will throw this point out. Upon further investigation by the AXIS team (we digested section 3.5 in WSDL 1.1), we decided this point is erroneous (it may still apply to MIME attachments, but I'll leave that for another discussion).
Here is out current position (and anyone in AXIS, PLEASE correct me if I've misunderstood our position!). #1 essentially points out that JAX-RPC does not detail the rules we should use for wrapped doc/lit. We made a guess based on the example in the spec. Our guess was clearly wrong from the TCK point of view. If we had concrete rules to follow, we'd be happy to follow them, assuming the second example shown in #2 were excised from the spec. That second example essentially tells us we don't have to follow ANY wrapped rules.
Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: Rahul Sharma <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: JAX-RPC TCK and wrapped doc/lit
Wed, 8-9 Pacific.
Toll Free: 888-576-4102
International: 484-630-3398
Passcode: 75258
Russell Butek
[EMAIL PROTECTED]
To: Russell Butek/Austin/[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: JAX-RPC TCK and wrapped doc/lit
[EMAIL PROTECTED] wrote:
> Rahul,
>
> We received your doc/lit comments at about the same time I sent out the
> note below. I don't believe your comments address these points.
>
> AXIS has a weekly telecon on Wednesdays, 8-9 AM. Might there be a chance
> that you (and Lance?) could join us for that hour? We might save
> ourselves some time if we could discuss this directly rather than
> swapping email every few days. If you can't make that time, then we look
> forward to your email response.
- Can you send me the teleconf details. I will try my best to attend.
Is it 8-9am PDT?
- Regards,
- Rahul
> Please respond to [EMAIL PROTECTED]
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: apache jaxrpc issues
>
>
>
> I haven't heard anything all week on this. I just want to keep this
> discussion going. Here is a list of reasons we have that the doc/lit
> test in the TCK is invalid (#2 should be enouh to justify our position
> that the doc/lit tests as they stand today are invalid, but it's not our
> only point).
>
> 1. The example from the TCK shown below does not follow the example in
> the spec. In the JAX-RPC example (and in .NET) the element name is the
> same as the operation name; in the TCK it is not. (from my original note)
>
> 2. JAX-RPC section 6.4.3 shows TWO possible Java mappings for the given
> WSDL. Therefore the TCK cannot mandate one. (from Rich's response)
>
> 3. Once upon a time JAX-RPC said that, if the binding info affects the
> signatures of the SEI methods, then the name of the SEI is derived from
> the name of the binding instead of the portType. JAX-RPC no longer says
> that. The implication of the absence of that statement is that the SEI
> will be the same no matter the binding. Consider a WSDL that contains
> the following:
> - a portType named "PT"
> - an rpc/encoded binding for "PT"
> - a doc/lit binding for "PT"
> The name of the SEI for BOTH these bindings will be derived from the
> portType "PT". Unless the SEI is the same for both, we have an interface
> clash. Therefore, the fact that a binding is doc/lit must not affect the
> SEI.
>
> Russell Butek
> [EMAIL PROTECTED]
>
> Please respond to [EMAIL PROTECTED]
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: apache jaxrpc issues
>
>
>
> Sam,
>
> I need Rahul to comment on Rich's concern. �Let us give him a little
> time and then I will follow-up again.
>
> Regards,
> Lance
>
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote:
> Lance/Rahul: Additional information on wrapped/doc lit, from Rich
> Scheurle....
>
> � � � JSR 101 v1.0 clearly indicates that the parameters of the
> � � � signature are
> � � � obtained from the message parts. �This information is used to
> � � � determine
> � � � order, holders, etc. �There is no mention of unwrapping an part's
> � � � element=
> attribute to populate the parameter list.
>
> � � � What if the complexType TradePriceRequest contained two elements
> � � � (tickerSymbol and companyName) ? �Would the TCK expect the following
> signature:
>
> � � � public float getLastTradePrice(String body, String body) throws
> � � � RemoteException; �// NOTE Two Parameters with the same name!
>
>
>
> Axis-dev'ers: below is outlook on schedule, process, etc.
>
> Everyone: what is the right process for Apache to approach the Expert
> Group? - Sam Ruby
>
> ---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 07/09/2002
> 01:40 PM ---------------------------
>
> To: Sam Ruby/Raleigh/[EMAIL PROTECTED]
> cc:
> Subject: Re: apache jaxrpc issues
>
>
>
> Hi Sam,
>
> Yes it was excellent thank you. �Could have used a bit more time but
> that is always the case after a holiday. �How was your 4th? �Hopefully
> you took some time off as well.
>
> Yes I am getting traffic on the list.
>
>
> For the content-id header, if either you or dims could fill out the
> template, that would be ideal. �I really need to know which tests and
> the section(s) of the spec which are in question. This just in, dims
> just sent me the challenge (and called me).... so I will take a look now.
>
>
> We are going to do a patch for jaxrpc based on the issues that you had
> raised previously and I have responded to. � �If you have other issues,
> please forward when you have a chance so that we can review. �My goal is
> to address any issues that we feel need patched. � Issues that do not
> get patched and we concur with, will be excluded. �I don't have an exact
> ETA for the patch as I want to see what other issues you have that we
> can address at the same time.
>
>
> I also followed up with Rahul again on the following issue. �He believes
> the tests are correct in their design. �His comments follow the issue
> description and your team's comments. �I think if there is still a
> concern, that it should be revisited in the Expert Group regarding the
> spec requirements. �Please let me know your thoughts.
>
> �>>>>
> �>>>> wrapped doc/lit
> �>>>> The TCK is expecting wrapped doc/lit signatures (like what .NET
> �>>>> does). �We do not believe it should.
> �>>>>
> �>>>> Here's a WSDL snippet from the TCK's stock quote test:
> �>>>>
> �>>>> <element name="TradePriceRequest">
> �>>>> �<complexType>
> �>>>> � �<sequence>
> �>>>> � � �<element name="tickerSymbol" type="string"/>
> �>>>> � �</sequence>
> �>>>> �</complexType>
> �>>>> </element>
> �>>>> <element name="TradePrice">
> �>>>> �<complexType>
> �>>>> � �<sequence>
> �>>>> � � �<element name="price" type="float"/>
> �>>>> � �</sequence>
> �>>>> �</complexType>
> �>>>> </element>
> �>>>>
> �>>>> <message name="GetLastTradePriceInput">
> �>>>> �<part name="body" element="xsd1:TradePriceRequest"/>
> �>>>> </message>
> �>>>>
> �>>>> <message name="GetLastTradePriceOutput">
> �>>>> �<part name="body" element="xsd1:TradePrice"/>
> �>>>> </message>
> �>>>>
> �>>>> <portType name="StockQuotePortType">
> �>>>> �<operation name="GetLastTradePrice">
> �>>>> � �<input message="tns:GetLastTradePriceInput"/>
> �>>>> � �<output message="tns:GetLastTradePriceOutput"/>
> �>>>> �</operation>
> �>>>> </portType>
> �>>>>
> �>>>> (the binding for this WSDL is doc/lit). �This is ALMOST like .NET's
> �>>>> doc/lit style. �But it's not quite. �AXIS generates:
> �>>>>
> �>>>> public TradePrice getLastTradePrice(TradePriceRequest body) throws
> �>>>> RemoteException;
> �>>>>
> �>>>> Unfortunately the TCK expects the following signature:
> �>>>>
> �>>>> public float getLastTradePrice(String body) throws RemoteException;
> �>>>>
> �>>>> We don't read anything in JAX-RPC that allows or requires this
> �>>>> signature, so we do not believe the TCK should expect this signature.
> �>>>
> �>>>
> �>>>
> �>>>
> �>>> � Doc/literal with wrapper is required as per 6.2. There is also an
> �>>> � example in section 6.4.
> �>>>
> �>>> � So this is not an issue.
> �>>
> �>>
> �>>
> �>>
> �>>
> �>> This is not an issue. I am expecting what the spec says regarding
> �>> doc/literal.
> �>>
> �>>
> <rjs>
>
> You are looking at the first mapping in section 6.4.3. Read futher in
> the same section. "Another possible mapping of the doExample method is
> as follows. In this example, the part named body in the DoExample
> message is mapped as xsd:complexType:
>
> DoExampleResponse doExample(DoExample body) throws
> java.rmi.RemoteException;"
>
> This is the kind of mapping that Axis uses. Also note that the last
> paragraph of 6.4.1 indicates that the mapping is specific to a JAX-RPC
> implementation and is not portable. So this is not a valid test.
>
> </rjs>
>
> As per specification, the section 6.2 requires support for wrapper
> element for doc/literal style of operations. This is used as part
> of the mapping. Please see details in this section 6.2.
>
> --- rahul's comments ----
>
> � � � The section 6.4.1 specifies mapping of literal message parts. In case
> � � � of standard required set of XML/Java types, use of doc/literal wrapper
> � � � style mapping is required as per the section 6.2. The spec can clarify
> this further (in maintenance release) if this is not entirely clear.
>
> � � � For extended (beyond the standard) set of XSD types, the mapping
> � � � to SOAPElement is the required mapping (per section 6.4.1). Spec also
> � � � allows implementation specific data binding (in absence of JAXB) but
> the latter is optional.
>
> � � � The section 6.4.2 provides examples about requirements in the section
> � � � 6.2 and 6.4.1. The intent of examples is to be illustrative. The
> requirements are still derived from sections 6.2 and 6.4.1.
>
> � � � So JAX-RPC requires doc-literal with wrapper style of mapping for
> � � � operations based on the standard required set of XML schema types.
> This is how TCK tests this case. So TCK tests are okay.
>
> � � � Beyond the standard set, mapping to SOAPElement is required with any
> � � � any implementation-specific data binding being optional. This with
> � � � additional requirement that a portable application should not rely on
> � � � any implementation specific data binding in the XML/WSDL->Java
> mapping.
>
>
>
>
> Regards,
> Lance
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote:
>
> �> I trust you had a nice holiday?
> �>
> �> Are you receiving axis-tck mailing list traffic yet?
> �>
> �> I'd like to start discussions with an issue concerning when the
> �> "Content-Id" headers (CID) for attachment parts are created. As near
> �> as we can tell the SAAJ TCK is dependent on the precise timing of when
> �> these ids are created by the TCK.
> �>
> �> How do we proceed?
> �>
> �> - Sam Ruby
>
>
> --
> Lance Andersen � � � � � � � � � � � email: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> Sun Microsystems Inc. � � � � � � � �phone: (781) 442-2037
> 1 Network Drive, UBUR02-301 � � � � �fax �: (781) 442-1610
> Burlington, MA 01803
>
>
>
>
> --
> Lance Andersen � � � � � � � � � � � email: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>Sun Microsystems Inc.
> �phone: (781) 442-2037
> 1 Network Drive, UBUR02-301 � � � � �fax �: (781) 442-1610
> Burlington, MA 01803
>
>
>
>
