[xsd-users] C++/Parser errors from GML schemas
boris at codesynthesis.com
Wed Oct 12 03:48:24 EDT 2005
James Boyden <jboyden at geosci.usyd.edu.au> writes:
> Firstly, I would like to commend the high quality of your software! It is
> a pleasure to find such a useful and well-designed C++ project. I applaud
> your use of the Boost libraries and your choice of an STL-based interface,
> I am impressed by your effective use of templates, and finally I am very
> appreciative of the alternative (SAX-like) approach to parsing offered by
> the C++/Parser mapping -- as you suggest in the C++/Parser Mapping Quick
> Guide , we already have an object model, whose structure and operation
> is dictated by the functionality of our software, so we would prefer to
> use our own data-types rather than the data-types provided by a mapping.
Thank you very much for kind words. Comments like this make us try all the
I guess we can now move to less pleasant matters ;-). I checked the schemas
you sent me (also added them to the repository of schemas we use for
regression testing). They use pretty much every feature there is in XML
Schema some of which, as you have discovered, are not yet supported by
I can divide these unsupported features into two categories: those that
we plan to support soon and those that have reasonably easy workarounds.
Accidently, the first category does not have easy workarounds. I will
go through them one by one below:
> - "expected 'list' or 'restriction' instead of 'union'"
This feature is from the second category. The workaround involves
creating a "binding" copy of the schema which is "wider" than the
original schema. You continue using the original schema for
validation (and give it to your clients, if any) and use "binding"
schema for code generation.
I realize that you would prefer to not modify the GML schemas but
that's the only way I can think of for now. To sweeten the deal
here are some positive sides:
* I assume new versions of GML schemas are not published very
often so there won't be too much of a maintenance headache.
* There is just a handful of places where you need to modify
* At some point xsd will support all missing features so you can
stop using two copies.
The workaround for union is to use a "base" type which is "wide"
enough to accommodate all union members. For example, the following
type from basicTypes.xsd:29
Can be changed like this for the purpose of code generation:
> - "mixed content model is not supported"
> - "expected 'group', 'choice', 'sequence' or 'element' instead of 'any'"
These will be supported in the upcoming release (due some time next week).
> - "expected 'extension' instead of 'restriction'"
These will be supported in 1.6.0 due end of the month.
There are also cases (found in measures.xsd) like this:
Which are equivalent to
- substitution groups
These will be supported in 1.6.0.
I am not sure whether these solutions are good enough for you but that's
the best we can do. While you will probably have to wait until 1.6.0 for
the whole thing to be supported (except unions), there are quite a few
individual schemas that don't have any unsupported features for which
you can start writing parsers.
Let me know if there is anything else we can do.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051012/bc5e16ea/attachment.pgp
More information about the xsd-users