It appears we do some renaming in Java. The schema ....
<xsd:schema targetNamespace="http://www.bigbank.com/AccountService"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";> <xsd:element name="getAccountReportResponse"> <xsd:complexType> <xsd:sequence> <xsd:element name="checking" type="xsd:string" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:complexType name="getAccountReportResponse"> <xsd:sequence> <xsd:element name="checking" type="xsd:string" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:schema> and the code .... public static void main(String[] args) throws FileNotFoundException { File inputFile = new File("src/main/resources/nameclash.xsd").getAbsoluteFile(); InputStream inputStream = new FileInputStream(inputFile); List testTypes = XSDHelper.INSTANCE.define(inputStream, inputFile.toURI ().toString()); for(Iterator it=testTypes.iterator(); it.hasNext(); ) { Type t = (Type)it.next(); System.out.println("type = " + t.getURI() + ":" + t.getName()); } } gives ..... type = http://www.bigbank.com/AccountService:DocumentRoot type = http://www.bigbank.com/AccountService:getAccountReportResponse type = http://www.bigbank.com/AccountService:getAccountReportResponse1 So I guess this is a different situation where the developer would have to do a bit of head scratching until noticing that there are two types created, one with a "1" postfix appended. Regards, Kelvin. On 08/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote: > I'll need to check but it will either be a) exception when adding the 2nd > type of the same name... or b) 2nd Definition replaces first... or c) > properties of 2nd definition are added to that of the first. > > Or... none of the above! What do you think the correct behaviour > should be? > What would Java do? > > Cheers, > I read the SDO spec again and it says that SDO types names must be unique within a particular namespace, and that you can use SDO name aliases if the names derived from the XSD names are not unique. I couldn't find any normative description of what will happen if you don't define the aliases. This other extract from the spec seems to imply that a generator should detect duplicate names and generate unique names, but it talks about a code generator tool. I'm not sure it means that the runtime should do it: <<<< Normally, SDO names are the same as the XSD names. To change the SDO name user can annotate an XSD with sdo:name annotations. In some cases, for example in the case of duplicate component names in XSD, the original XSD names cannot be preserved in SDO. In such cases, an SDO-aware code generator tool will generate new names and virtually add sdo:name annotations to the original XSD. Then, the tool will use the Annotated Schema to generate SDO. Such tool must be able to serialize the Annotated Schema at user request. >>>> I suspect that the current C++ runtime does "(c) properties of the second definition added to that of the first", because I ran into a strange situation when I was working on bringing-up the BigBank scenario, where I had mistakenly defined AccountService.wsdl in both the wsdl and xsd sections of Tuscany-model.config and was seeing 2 customerID properties in the getAccountReport type... It took me a while to figure it out :) My personal preference would be to get an exception from defineType or defineFile, forcing the user to use unique names instead of just thinking that everything is OK and only realize that types with identical names got mashed together after a few hours of head scratching and debugging... It is not a strong preference though, and it's really a corner case so we probably don't need to complicate the runtime to throw that exception and I'm also fine with the current behavior. What do you guys think? Any opinions on how this should be handled from the Java Tuscany SDO folks? -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Best Regards Kelvin Goodson
