[xsd-users] CityGML 1.0.0 and C++/Parser interface

[Boris Kolpackov]

Hi Oleg,

Oleg Dedkow <odedkow at gmx.de> writes:

> I'm trying to generate C++ classes for the CityGML 1.0.0 schemas (please, 
> see the attached ZIP file) using C++/Parser interface. I'm using xsd 3.2.0
> and was able to generate C++ classes using C++/Tree interface. However,
> this does not fit my needs, since I have to handle very large CityGML 
> files that could not fit into memory.  I get the following error using 
> C++/Parser interface:
>
>  dictionary.xsd:43:79: error: unable to match restricted particle

The C++/Parser mapping is not yet capable of handling GML. GML uses
non-trivial complex type restrictions that are not yet support. Also,
the GML schemas are very complex, they use XML Schema polymorphism
extensively, so handling CityGML document with C++/Parser is going
to be a lot of hard work.

If I were in your situation I would use C++/Tree but parse the documents
chunk by chunk. Here is how I would do it: I would create a top-level SAX
parser which constructs DOM fragments for portions of the document. Once
the chunk is ready, the parser creates the corresponding C++/Tree object
model and frees the DOM fragment. The object model can then be used by the 
application. Once the object model is processed, it is freed and the SAX
parser moves on to the next chunk. This way you can handle fairly large
CityGML/GML documents and remain sane at the same time ;-).

As an example, consider this XML document:

<records>

  <header>
    <name>Sample records</name>
    <id>sample001</id>
  </header>

  <record id="0">
    ...
  </record>

  ...

  <record id="10000">
    ...
  </record>

<records>

With the above approach the SAX parser will first create a DOM fragment
corresponding to:

  <header>
    <name>Sample records</name>
    <id>sample001</id>
  </header>

And parse it to the object model. This object model can then be kept
around or processed and discarded. Then the parser will create a DOM
fragment for each record, parse it to the object model, process, and
discard.

This approach is very similar to the partially in-memory/partially
even-driven XML processing that we do in XSD/e (in embedded systems
even relatively small documents can be too large to fit into RAM). 
See Section 6.1, "Customizing Parsers and Serializers" in the 
Embedded C++/Hybrid Mapping Getting Started Guide for details on 
how this works in XSD/e:

http://codesynthesis.com/projects/xsde/documentation/cxx/hybrid/guide/#6.1

If you are interested, I could create an example that shows how to do
all this with C++/Tree.


> The above-mentioned error is caused by the dictionary.xsd schema which
> [...] will it be possible to create some workaround? It would be OK for
> me to edit the local GML schemas.

You could probably "relax" the GML schema a bit and make it compile with
C++/Parser. What causes the above error is the use of an element
substitution in restriction. Here is an example (here Derived1 is derived-
by-restriction from Base1):

<element name="base" type="Base1">
<element name="derived" type="Derived1">

<complexType name="Base2">
  <sequence>
    <element ref="base"/>
  </sequence>
</complexType>

<complexType name="Derived2">
  <complexContent>
    <restriction base="Base2">
      <sequence>
        <element ref="derived"/>
      </sequence>
    </restriction>
  </complexContent>
</complexType>

You can "relax" the above schema by using base instead of derived in
Derived2.

Boris