[xsd-users] different behavior by xsd 3.0 and 3.2

[Jeffrey Yu]

Boris,

Yes, it is caused by the use of "value_type" in my xsd file.  It seems the
"type" is a popular word in the world of programming.
Do you think it is possible to deploy a better name mangling mechanism in
xsd compiler so variable names can be unique and don't collide 
With the user-defined variables?

After making the changes, I run into a different problem:
 
The use of TSInput.xsd are in two different projects binding under one
solution, I am talking in Visual Studio 2005.
The first project is served as a static library while the 2nd one is the
front end.

Both projects call xsd.exe to produce the data binding objects as their own
pre-build event.  Here is the problem:
The preprocessor put at top of the .hxx are different.  My guess is the
location of the xsd is used as part of the preprocessor.
If the xsd is in the default location, the name of the file is used to
construct the preprocessor, TSINPUT_HXX for instance.
However, when the project is in a different location other than where xsd
is, the relative path is placed in front of the file name.

As such, TSInput would be wrapped under two different preprocessors.  In my
case here, the front end references to the header file.
It comes to realize TSInput has been created.  

In short, it is the preprocessors placed in top of the .hxx have the
different names caused the problem.


Jeff


-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Monday, October 06, 2008 9:29 AM
To: Jeffrey Yu
Cc: XSD-users
Subject: Re: [xsd-users] different behavior by xsd 3.0 and 3.2

Hi Jeffrey,

Jeffrey Yu <jeffrey.yu at panpacificinvestment.com> writes:

> The problem is with the attribute named "value_type" of YCInput. In the
> xsd file, the type is "string". It becomes "decimal" in TSInput.hxx.

What happened is that the duplicate name escaping algorithm has changed
since 3.0.0. Here is what happens in more detail: your have the following
two attributes in YCInput:

<xs:attribute name="value" type="xs:decimal" default="0" />
<xs:attribute name="value_type" type="xs:string" default="NOT_DEFINED" />

In XSD 3.0.0 they were translated into these declarations:

  // value
  // 
  typedef ::xml_schema::decimal value_type1;

  const value_type1&
  value () const;

  // value_type
  // 
  typedef ::xml_schema::string value_type_type;

  const value_type_type&
  value_type () const;

As you can see the typedef name for the 'value' attribute conflicted
with the name of the 'value_type' attribute and was escaped to 
value_type1. Now here is what's generated by XSD 3.2.0:

  // value
  //
  typedef ::xml_schema::decimal value_type;

  const value_type&
  value () const;
 
  // value_type
  // 
  typedef ::xml_schema::string value_type_type;

  const value_type_type&
  value_type1 () const;

As you can see, the algorithm has changed slightly and now the second
occurrence of value_type is escaped. This change was made to make the
outcome of type escaping more predictable. The original logic was
trying to be clever in some simple cases like the above but was not
very consistent in some more complicated situations.

The root of the problem here is that the type names and function
names use the same naming conventions. Since 3.1.0 you can select
naming conventions for types and functions from a list of predefined,
widely-used conventions (you can also fine-tune this to provide your
custom convention). We can for example switch to the "upper camel case"
type naming to resolve the above problem:

$ xsd cxx-tree --type-naming ucc TSInput.xsd

This will result in the following definitions:

  // value
  // 
  typedef ::xml_schema::Decimal ValueType;

  const ValueType&
  value () const;

  // value_type
  // 
  typedef ::xml_schema::String Value_typeType;

  const Value_typeType&
  value_type () const;

For more information on naming conventions see the NAMING CONVENTION
section in the XSD Compiler Command Line Manual:

http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml

Boris