[xsd-users] C++/Parser errors from GML schemas

[James Boyden]

On Wednesday, Oct 12, Boris Kolpackov wrote:

> Thank you very much for kind words. Comments like this make us try all the
> harder! :-)

Even if you "only" keep trying as hard as you are now, we will be happy!
:-)

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

> 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
> 
> <simpleType name="NullEnumeration">
>     <union>
>       [...]
>     </union>
> </simpleType>
> 
> Can be changed like this for the purpose of code generation:
> 
> <simpleType name="NullEnumeration">
>   <restriction base="string"/>
> </simpleType>

OK, I applied these changes to my local copy in the appropriate places.

> >  - "expected 'extension' instead of 'restriction'"
> 
> These will be supported in 1.6.0 due end of the month.

I attempted to temporarily avoid these problems in my local copy by
removing, where necessary, the smallest amount of the unsupported XML. 
Unfortunately, there were more instances of this problem hidden in the
schemas, which didn't appear until the first instances were "fixed".  As I
fixed these new ones, even more appeared.  Eventually I decided there were
too many to fix (I spent a few hours chasing them).

So, I suppose we will need to wait until the 1.6.0 release before we can
evaluate xsd further.

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

Thank you for your help so far; we look forward to the release of 1.6.0!

Regards,
James Boyden

-- 
 James Boyden <jboyden at geosci.usyd.edu.au>
   GPlates Programmer and Keeper of the Flame,
     School of Geosciences, University of Sydney, Australia.
      "I find your lack of faith disturbing."