Hi Rob,
>
>
> in essence, we need to decide if we care about supporting deprecated
> or removed stuff (an overly lax gml3.2), if so, what mechanism could
> we use to catch such exceptions.
Without knowing a lot about the specifics, i would say yes. My rationale
being things like gml:MultiPoly
There is a list of changes at doc OGC 07-061
first, the theory...
"Note that since the target is backwards compatibility of the
instances and not the application schemas, outdated types (and
abstract elements) have been removed and not deprecated whenever
possible."
Moist changes seem to be depr
Hi Rob,
Do we have a list of types between 3.1.1 and 3.2 which are different?
Instead of creating a new module i think it might be best if we kept the
new 3.2 binding in the same module, perhaps just a different package. W
e can then create a new GMLConfiguration class for the new bindings. I
Hi Justin,
I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and
it looks like the bindings for gml 3.1.1 are basically re-usable for
gml3.2 support. I know we'll need a new binding (gml:identifier,
basically a gml:name)
it seems that its the tests which are most heavily bound to
