+1 on number two. I like detecting the collision and munging the name.
+1 on waiting to make them inner classes. :-) -- Tom Jordahl -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 11:03 AM To: [EMAIL PROTECTED] Subject: Re: duplicate element name in different complexType elements. Tom, Ouch! The problem is that the embedded return elements both have anonymous types. The emitter needs to generate a name for the anonymous types, so it chooses the most reasonable name (return). This results in a collision. Brainstorming...... 1) I like the fact that we use the name "return" for the anonymous type. This is a nice solution in the majority of cases. But this can result in a collision, like this testcase... 2) We could detect the collisions and munge the name of the anonymous type....i.e. name one return_anon### (where ### is a unique number). This would require changing the referent element in the symbol table to refer to the new special qname. 3) Could always generated nested anonymous types as inner classes? This might be the ultimate solution, but there is no support for this yet in the emitter. Plus I don't want to complicate the Bean class until after the meta data issue is resolved. So I think 2 is the correct approach for now. Agree ? Comments ? Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) Tom Jordahl <tomj@macromedia. To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> com> cc: Subject: duplicate element name in different complexType elements. 03/12/2002 09:48 AM Please respond to axis-dev This WSDL: http://services.xmltoday.com/vx_engine/wsdl.vep?flight.wsdl Gives this error: java.io.IOException: urn:vgx-flight:return already exists The error is correct, there are two instances of "return" in the same namespace, but they are in different complexType declarations. I am afraid this might be hard to address given the way we put entries in the Symbol Table. Rich, could you take a look at this? Can we process this WSDL correctly? -- Tom Jordahl Macromedia Server Development
