[xsd-users] RE: Possible Oversight

[Manav Rathi]

> > >...the code bloat which happens when you reference the same element
> with
> > anonymous type in two or more other types. In this situation the same
> nested
> > type will be generated in several places...
> >
> > This I did not know. So, if I use the same anonymous type within two
> > different elements, then xsd will recognize it as so, and emit only a
> > single instance of the common anonymous type. Nice.
> 
> Not exactly. The scenario I was referring to is the following:
> 
> <element name="e">
>   <complexType>
>     ...
>   </complexType>
> </element>
> 
> 
> <complexType name="a">
>   <sequence>
>     <element ref="e"/>
>   </sequence>
> </complexType>
> 
> <complexType name="b">
>   <sequence>
>     <element ref="e"/>
>   </sequence>
> </complexType>
> 
> Here, if we generate nested classes for anonymous types, you will end
> up with the following code:
> 
> class a
> {
>   class e
>   {
>   };
> };
> 
> class b
> {
>   class e
>   {
>   };
> };
> 
> The way XSD works, you will only get one (global) class e which is used
> by both a and b.
> 



What I was suggesting is something like this.


<element name="root1">
 <complexType>
  ...
  <element name="child">
   <complexType>
   ...
   </complexType>
  </element>
  ...
 </complexType>
</element>
     
<element name="root2">
 <complexType>
  ...
  <element name="child">
   <complexType>
   ...
   </complexType>
  </element>
  ...
 </complexType>
</element>


results in generation of 


class root1
{
 class child {};
};

class root2
{
 class child {};
};


However, there will be a problem with this approach. We cannot have a nested
class and a member function with the same name. So we try and rename the
nested classes. 


class root1
{
 class child_type {};
 child_type & child();
};

class root2
{
 class child_type {};
 child_type & child();
};


Contrasting with the solution xsd currently uses

class child_type {};
class child_type1 {};

class root1
{
 typedef child_type child_type;
 child_type & child();
};

class root2
{
 typedef child_type1 child_type;
 child_type & child();
};


I can see that we get the same syntax (i.e. one can refer to the nested
types as root1::child_type and root2::child_type), but can still avoid all
the complexity associated with deeply nested types. So the current design of
XSD wins :)

However, there *seems* to be a problem - the child types are now available
in the global namespace (i.e. I can do ::child_type and ::child_type1). 

Whether this is good or bad, I am not too sure. The most obvious advantage
is that I get to type less (i.e. child_type instead of root1::child_type).
The most obvious disadvantage is that encapsulation is broken (i.e.
child_type should not mean anything unless it is a root1::child_type).

As I said before, right now I consider this as a problem. And as a solution,
I am using the --anonymous-regex switch to rename the root1::child_type
class to a much more verbose root1_child_type, so that programmers prefer
the nested root1::child_type typedef to the global root1_child_type actual
class.