Sam wrote: > > Russell Butek wrote: > > > > Dang! Interop tests! I KNEW I forgot to check something! I'm on it... > > Cool. >
Fixed. > > So what do folks think? Should I get rid of the xsd:date mapping? It's > > not part of JAX-RPC and I don't believe users have complained that we > don't > > have it. > > One thing I do agree is that xsd:date should not be the default mapping for > java.util.Date, given that it is a lossy conversion. > > Ulimately, I believe that people will move to a WSDL first methodology. > Given this, I believe that the fiction of a 1-to-1 and onto mapping will > ultimately break down. I disagree. We thought the same thing about IDL, but it didn't happen. In the Java world folks will write EJBs. They won't care about the transport protocol. So roundtripping will continue to be an issue. > > Both java.util.Date and java.util.Calendar should map to *BOTH* xsd:date > and xsd:dateTime, with metadata (reflection, skeleton interfaces, WSDD or > the like) helping the runtime distinguish between the various cases. And > with the current scheme providing reasonable defaults for the 90% use > cases. > > It is worth noting that only TCL appears to adequately support xsd:date at > the moment. > > My recommendation for the short term: drop xsd:date and handle both > java.util.Date and java.util.Calendar as xsd:dateTime in much the same way > that we handle multple mappings to SOAP-ENC:Array. People who are using > java.util.Date based on Apache SOAP's mapping (or prior betas of Apache > Axis) will appreciate it if we do. > We can do this, and we probably should, but just because we already do it with SOAP-ENC:Array doesn't mean it's a good idea in the long run. This can be a problem with roundtripping.
