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

Boris Kolpackov boris at codesynthesis.com
Wed Oct 12 03:48:24 EDT 2005


James,

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 [1], 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
harder! :-)

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

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

  * 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

<simpleType name="NullEnumeration">
    <union>
      <simpleType>
        <restriction base="string">
          <enumeration value="inapplicable"/>
          <enumeration value="missing"/>
          <enumeration value="template"/>
          <enumeration value="unknown"/>
          <enumeration value="withheld"/>
        </restriction>
      </simpleType>
      <simpleType>
        <restriction base="string">
          <pattern value="other:\w{2,}"/>
        </restriction>
      </simpleType>
    </union>
</simpleType>

Can be changed like this for the purpose of code generation:

<simpleType name="NullEnumeration">
  <restriction base="string"/>
</simpleType>


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

<complexType name="LengthType">
  <simpleContent>
     <restriction base="gml:MeasureType"/>
  </simpleContent>
</complexType>

Which are equivalent to

<complexType name="LengthType">
  <simpleContent>
     <extension base="gml:MeasureType"/>
  </simpleContent>
</complexType>


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

thanks,
-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051012/bc5e16ea/attachment.pgp


More information about the xsd-users mailing list