It's intentional... This is the unwrapped type (wrapperStyle=false), but we define a source-databinding wrapper (non-null) to help us transform to the wrapped type.
Though the names aren't the best.. I don't think it's too bad until we added the 'sourceBare' to the mix. I think Raymond added this... correct if I'm wrong... but I think the reason we need it is that we might have a @SOAPBinding BARE annotation in Java mapped to a WSDL that would actually qualify for wrapper style. Since our introspection/construction of the Java and WSDL interfaces happen separately... we can't take the Java into account when introspecting the WSDL. So we need a flag that says.. though the WSDL looks like there should be a wrapping/unwrapping along with the transform... we actually don't want one. Simon mentioned in our offline conversation that you'd think in most cases only the bare/wrapped mapping would even be valid, but you can imagine a signature like: void myMethod(DataObject obj) where the same Java could map to either the wrapper element or its single child. So we signal that we should go down that third block (child->child mediation with no wrapper) by choosing to not create a wrapper when we introspect the Java, and then calculating 'sourceBare' as we do in I2I. I think that's what's going on anyway.. I do think if we started from scratch and considered all the combinations of the wrapped vs. bare Java/WSDL interfaces we could probably find a clearer way of naming/coding this.. but I'm not sure it's worth taking it that far.. but reanming the sourceBare check as we discussed would be nice. Scott
