Schemas/CityGML
From Code Synthesis Wiki
| Revision as of 13:52, 21 October 2009 Boris (Talk | contribs) (Add a note on substitution groups issue during serialization) ← Previous diff |
Revision as of 14:09, 21 October 2009 Boris (Talk | contribs) Next diff → |
||
| Line 3: | Line 3: | ||
| One issue with the CityGML schema is its use of substitution groups as application-significant IDs rather than just a way to specify the element types. For example, element cityObjectMember is of type gml:FeaturePropertyType and substitutes gml:featureMember which is also of type gml:FeaturePropertyType. 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 issue with the CityGML schema is its use of substitution groups as application-significant IDs rather than just a way to specify the element types. For example, element cityObjectMember is of type gml:FeaturePropertyType and substitutes gml:featureMember which is also of type gml:FeaturePropertyType. 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. These information is automatically extracted during parsing, can be queried/modified by the application, and is used during serialization to make sure the right element name is used. With this change the serialized XML is equivalent to the original. | + | 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/modified by the application, and is used during serialization to make sure the right element name is used. With this change the serialized XML is equivalent to the original. |
| The following package contains the official CityGML 1.0.0 and GML 3.1.1 schemas placed into single directories. It also contains the custom xml_schema::type implementation as discussed above, a simple test driver for the C++/Tree mapping, makefile, and option files used to compile the schemas. | The following package contains the official CityGML 1.0.0 and GML 3.1.1 schemas placed into single directories. It also contains the custom xml_schema::type implementation as discussed above, a simple test driver for the C++/Tree mapping, makefile, and option files used to compile the schemas. | ||
Revision as of 14:09, 21 October 2009
This page contains information on using the CityGML (representation, storage, and exchange of virtual 3D city and landscape models) schemas with XSD. CityGML 1.0.0 depends on GML 3.1.1. See the GML page for more information on how to use the GML schemas with XSD. Both schemas use XML Schema polymorphism in the form of substitution groups.
One issue with the CityGML schema is its use of substitution groups as application-significant IDs rather than just a way to specify the element types. For example, element cityObjectMember is of type gml:FeaturePropertyType and substitutes gml:featureMember which is also of type gml:FeaturePropertyType. 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/modified by the application, and is used during serialization to make sure the right element name is used. With this change the serialized XML is equivalent to the original.
The following package contains the official CityGML 1.0.0 and GML 3.1.1 schemas placed into single directories. It also contains the custom xml_schema::type implementation as discussed above, a simple test driver for the C++/Tree mapping, makefile, and option files used to compile the schemas.
For ideas on how to handle very large CityGML documents using the C++/Tree mapping, see the CityGML 1.0.0 and C++/Parser interface thread on the xsd-users mailing list.
