Talk:Schemas/GML
From Code Synthesis Wiki
| Revision as of 02:52, 27 September 2006 Dr shorthair (Talk | contribs) ← Previous diff |
Revision as of 13:18, 2 October 2006 Boris (Talk | contribs) Next diff → |
||
| Line 10: | Line 10: | ||
| I'd be interested to hear your results/recommendations for whether this works, and what fixes might help? | I'd be interested to hear your results/recommendations for whether this works, and what fixes might help? | ||
| + | |||
| + | :I can think of only one way to adress this problem: pass the inconvenience to the end user ;-) by generating each class into a separate file, just like Java binding tools do. This is obviously not as clean as mapping xsd:include/xsd:import to CPP #include and, in case of schemas like GML, can result in thousands of files being generated which will lead to longer compilation times, etc. It will also complicate the compiler quite a bit so there is no guarantee if/when we will implement this feature. | ||
| + | |||
| + | :I am also not sure of your role in GML 3.2 / ISO 19139: are you working on the standard and looking for ways to make it more compatible with data binding tools or are you trying to use the standard to generate a C++ binding? -- [[User:Boris|Boris]] 09:18, 2 October 2006 (EDT) | ||
Revision as of 13:18, 2 October 2006
On the top page you refer to the "pathologically circular dependencies" within part of the GML schema. Unfortunately I suspect it only gets worse in GML 3.2. This particularly relates to the dependencies between the CRS-related schema and the Metadata schema from ISO 19139. The schema documents for ISO 19139 are available here:
http://eden.ign.fr/xsd/isotc211/20060608/view
in a bundle that also includes GML 3.2 with the schemaLocation paths all set up to be local/relative paths. Note that this bundle *only* validates as a whole - due to the transitive/circular import and include chains, it is not possible to validate the whole from any place other than either gmd/gmd.xsd or gml/gml.xsd (not quite sure which).
I'd be interested to hear your results/recommendations for whether this works, and what fixes might help?
- I can think of only one way to adress this problem: pass the inconvenience to the end user ;-) by generating each class into a separate file, just like Java binding tools do. This is obviously not as clean as mapping xsd:include/xsd:import to CPP #include and, in case of schemas like GML, can result in thousands of files being generated which will lead to longer compilation times, etc. It will also complicate the compiler quite a bit so there is no guarantee if/when we will implement this feature.
- I am also not sure of your role in GML 3.2 / ISO 19139: are you working on the standard and looking for ways to make it more compatible with data binding tools or are you trying to use the standard to generate a C++ binding? -- Boris 09:18, 2 October 2006 (EDT)
