[xsd-users] Some difficulties with GML/CityGML Tree Parser generation : a bug?

[Boris Kolpackov]

Hi Erwann,

Erwann HOUZAY <erwann.houzay at ign.fr> writes:

> I use the following to produce a C++ libs for GML and CityGML:

Do you put all the generated code into a single DLL or multiple
DLLs?


>  <p2:featureMember xmlns:p3="http://www.w3.org/1999/xlink" p3:type="simple"/>
>
> What had happen to the "cityObjectMember"?

This is actually quite tricky. Element cityObjectMember is of type 
gml:FeaturePropertyType and substitutes gml:featureMember. But
gml:featureMember is also of gml:FeaturePropertyType. In other words,
the substitution doesn't introduce a new type but just changes the 
element name. This doesn't not work well with XSD because during 
serialization the generated code uses object model types to 
automatically figure out which element name to use based on the 
substitution group information from the schemas. As a result, the 
generated code always uses featureMember since it has the same type 
as cityObjectModel. 

One way to overcome this in the C++/Tree mapping is to customize the 
xml_schema::type class (which is the base type for all the generated 
classes) by adding a custom element name and namespace members. This
information is automatically extracted during parsing, can be queried
and modified by the application, and is used during serialization to 
make sure the right element name is used. I have implemented this and
uploaded a new version of the test driver for CityGML:

http://wiki.codesynthesis.com/Schemas/CityGML

With this change and with a small fix to your sample XML:

  <CityObjectGroup gml:id="g_12529">
  </CityObjectGroup>

Should be:

  <grp:CityObjectGroup gml:id="g_12529">
  </grp:CityObjectGroup>

The serialized XML is equivalent to the original.

Let me know if this doesn't work for you.

Boris