Raymond, Ah..thanks for the clarification...I think I see what you're saying.
I like the fact that you've reduced the number of flags directly involved in the transform from three to one. I think your organization would require some extra knowledge in something like Input2Input to track which side in WSDL and which side is Java, however. Let me walk through this to see if I understand: So if I start from Java with @SOAPBinding.parameterStyle == ParameterStyle.BARE, we'd calculate: dataWrapped = true wrapperRequired = false We'd generate a WSDL with dataWrapped=false (copying the wrapperRequired = false from Java). So this would take us down: 3.2 sourceOperation.dataWrapped && !targetOperation.dataWrapped (wrapper --> bare) which means: QuoteResponse getQuote(Quote) --> doc-lit // 3.2 The last line signifies that we want to transform "directly", without any wrapping, (or unwrapping). Your examples all flow in the Java->WSDL direction. But note we're also going to need to use this same transform: 3.2 sourceOperation.dataWrapped && !targetOperation.dataWrapped (wrapper --> bare) in the case where we have a Java with @SOAPBinding.parameterStyle == ParameterStyle.WRAPPED (the default of course) , as we go from: doc-lit-wrapped --> float getQuote(String) So in the Java->WSDL direction, it would seem like wrapper->bare means that you transform without any wrapping or unwrapping, whereas in the WSDL->Java direction, it seems like the wrapper->bare transform means that you do an unwrapping. This adds an asymmetry that's not there today...right? I'm going to stop there and see if you agree, as maybe I still haven't understood totally correctly. I am curious to also understand the cases where there does exist an existing WSDL, especially the case I mentioned which I think is a bit tricky (where the WSDL exists and would qualify for wrapper-style-mapping per JAX-WS but where the Java has the ParameterStyle.BARE annotation). ---- Some other thoughts: It might take awhile to mentally untangle the fact that a "wrapped" Java interface translates into dataWrapped=false. (Then again, making sense of the status quo isn't exactly easy). In saying that the ParameterStyle.BARE Java means "dataWrapped=true", you're not so much saying that it's necessarily wrapped... but you're saying it doesn't need to be wrapped along with transformation to another data format. I would say that: dataWrapped = true translates into: dataStillNeedsToBeWrapped=false And having made that connection, agree that it is simpler to deal with dataWrapped than an equivalent in my terms of: ! dataStillNeedsToBeWrapped ----- Scott
