[xsd-users] GML 3.2.1 and xsd-parser

[David White]

Hi Boris and xsd-users,

May I echo what many others have said - many thanks for your tireless work
and support on this excellent product!

I was wondering if you could provide a brief update on current status of
C++/Parser handling GML.  Looking through the xsd-users mail, I understand
there has been quite a bit of action in the GML space since Oleg's email
below, and I have read your wiki on GML (
http://wiki.codesynthesis.com/Schemas/GML).  Recently, I have been trying
to generate c++source for a GML 3.2.1 application schema using xsd-parser
and am coming up with the same error as Oleg:

gml\3.2.1\dictionary.xsd:34:79: error: unable to match restricted particle

Is there a solution to this or should I continue to follow your advice to
Oleg below.

Thanks.

David.


On Fri, Apr 17, 2009 at 12:40 AM, Boris Kolpackov
<boris at codesynthesis.com>wrote:

> 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
>
>