Hi Tom, Thanks for the helpful response. Here are some additional notes in answer to your questions: re: validation -- web services clients typically need to assemble object graphs that get sent out over the wire to do some useful work. A well behaved client will make an effort to avoid sending garbage to the server. So, if the schema the two agreed to abide by says that a must have a , a well-behaved client will not permit its invoker to send a nameless person (Person p = new Person(); p.setName(null);) over the wire. So, it would be useful to have the capability to check that such objects are indeed valid before sending them to the server. You could imagine that this would be implemented as a Handler in the chain of handlers that precede the transport-pivot in Axis and that users might only enable such a handler during development. This class of validation could be termed "content model integrity" -- it would include checks for conformance to cardinality (don't exceed maxOccurs) and composition (which branch of an xs:choice are you sending?). A simpler, but no less useful kind of validation would enforce facets on member variables whose type is simple. So, if the schema says that bears an xs:short between -4 .. 63, you would expect public void setFoo(short s); to throw an IllegalArgumentException when s doesn't fall in the prescribed range. Ditto for regex facets and the like. You might imagine that this kind of code would be optionally emitted by the code generator -- useful during development; possibly undesirable in production code. re: xerces itself. Unfortunately it's all in the same jar. However, I don't think (not sure) that the mere presence of Xerces in the classpath causes it to usurp the place of, say, Crimson as the XML parser returned by the JAXP apis. I think you have to specifically configure the runtime to replace the "standard" parser as of java 1.4. (again, not sure). Given that it's desirable to support most/all of Schema from within axis, I wonder: should we tackle this challenge again, ourselves? Or should we punt and point people to the schema -> java generators provided by Castor and JAXB, both of which are quite complete but not licensed under Apache licenses? Eric -----Original Message----- From: Tom Jordahl [mailto:tomj@macromedia.com] Sent: Thursday, August 14, 2003 2:16 PM To: 'axis-dev@ws.apache.org' Subject: RE: WSDL2Java code generation req'ts Eric, I think we have always wanted to support as much of XML Schema as we can. The JAX-RPC list is a bare minimum and certainly we support more than that. +1 to replacing the Schema parser in WSDL2Java. +50 to adding support for more(all?) schema types in 1.2. JAX-RPC is going to synchronize with JAXB at some point and get out of the business of parsing XSD and mapping to Java. The problem is that they (and we) need to go both ways Java->XSD and XSD->Java. 1+ years ago, JAXB wasn't done with a single direction. It would be awesome to throw out 99% of our code and just use a jar file to do this work. :-) I am confused about what validation (and when) you want to do. Could you clarify that? Does using Xerces mean we will have a hard dependancy on it, or is the Schema stuff in a different jar file? -- Tom Jordahl -----Original Message----- From: Eric.D.Friedman@wellsfargo.com To: axis-dev@ws.apache.org Sent: 8/14/2003 1:05 PM Subject: WSDL2Java code generation req'ts Can someone please tell me what level of support WSDL2Java is required to have vis-a-vis XML schema? Is it *just* what's described in the JAX-RPC spec? Do we want to tackle some/any/all of what's in the JAXB spec, or is that entirely out of scope? I am asking as a follow-up to the recent discussion about the performance of WSDL2Java. As I mentioned in that thread, I believe it's possible to get dramatically better performance using the schema parser in Xerces. Indeed, I know it's possible, as I've hacked together a working prototype to generate java beans from complex types and it's a lot faster than wsdl2java. So, the question before you is what's the minimum level of schema support WSDL2Java is required to have? Clearly JAX-RPC is included, but is that it? Or do we want to (need to) add support for xs:choice, substitution groups, and so forth? Some nice-to-haves that I can think of are: (1) some degree of validation support; (2) transfer elements to the javadoc for the corresponding types/instance variables. Thanks, Eric