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]
