Questions regarding the CSW 2.0.2 bindings.

[avautour]

trafficstars

We ran into the issue where the CSW 2.0.2 bindings return java.lang.Object instead of the expected OGC Filter object.

That change in behaviour looks to have been to reduce the context mappings needed to unmarshal a CSW 2.0.2 document.

While I can certainly appreciate the size of the dependency tree for that schema and we could certainly work with those generated bindings, it is a shame to have to trade off compile-time type safety for dynamic runtime checks.

@highsource, could you elaborate on why you felt the mappings needed to be reduced? Was there a problem that was encountered that this was trying to solve? Were you just trying to make it easier for a client to set up the context object? Did you want a smaller footprint for the JavaScript bindings?

[highsource]

I've thought a bit about it. You're right, the refactoring back then was because of the dependency tree and Jsonix mapping. I was irritated by the fact that I need to load 9 schemas to parse XML which does not even have elements from these schemas.

Now that you've asked I gave it another thought. I think you're right, it is not the right way to fix this. This must be actually fixed in Jsonix. I've files an issue in Jsonix (see highsource/jsonix#100) which should allow to build Jsonix contexts with incomplete list of mappings. When this is resolved, I'll revert these changes.

[avautour]

The work around for this is proving to be more complicated that I had expected. Originally, I thought the the wildcard=lax would have led to the unmarshalled Object instance to be of type FilterType, which would have meant that the only change to existing code would have been:

// Before
QueryConstraintType constraint = ...;
FilterType filter = constrait.getFilter();
// After
QueryConstraintType constraint = ...;
FilterType filter = (FilterType) constrait.getFilter();

Problem is, it unmarshalls to a JAXBElement<FilterType>. That means that any existing code that called setFilter() with a FilterType in our codebase is probably incorrect, even though it still compiles.

All that to say, I was wondering if you'd be willing to change just the Java bindings for now, and leave the JSON bindings until you had a chance to work on that JSON issue. That would simplify things on our end, without unnecessarily raising the urgency on that JSON issue. Would that be an acceptable compromise to you?