Rob Atkinson wrote:
> Justin Deoliveira wrote:
>> Gabriel Roldán wrote:
>>> Hi ran into problems when dealing with feature construction or attribute type
>>> evaluation and supertypes.
>>> basically I need supertypes to be taken in count both by AttributeBuilder and
>>> by Xpath over AttributeTypes. That is not happening right now, so when
>>> constructing a feature with AttributeBuilder and trying to assign an
>>> attribute declared in a supertype it fails.
>>> For the case of xpath over a FeatureType to find out the AttributeDescriptors
>>> in supertypes I extended Descriptors.node(ComplexType, String) to handle
>>> But the question is how do we are supposed to deal with supertypes:
>>> 1: at FeatureType creation type just apppend all the properties of its super
>>> 2: Look up on the type hierarchy every time its needed. Mainly on the Types
>>> utility class and on AttributeBuilder.
>>> 1) seems straight forward, 2) seems more correct.
>> Hmm, tough one indeed. Both have benefits. I see 1 being more efficient,
>> and resulting in simpler code as the "hierarchy walking" is only done
>> once at type creation time. However 2 does make more sense from a data
>> structure point of view.
>> What I want to avoid is defining inheritance logic in multiple places.
>> ie, one piece of code may interpret inheritance to mean restriction,
>> others to be extension, etc... By creating the type as with 1 we kind of
>> avoid this. I guess we could also break out a convenience method for 2.
>>> And given the modeling power of FM I guess if subtype declares an attribute
>>> with the same than one of the supertype, that is an override? the overriding
>>> descriptor should have a "compatible" type (derived from) with the overriden
>>> one, or it could just override multiplicity.
>> Good question. I faced this same problem. When I was working on fm I
>> tried to enforce a restriction that an overriding attribute had to be a
>> subclass of its parent. But found that it was too restrictive. ie, there
>> were places where the java type hierarchy did not mirror the xml type
>> hierarchy. For instance consider the xml schema types "long" and "int".
>> In xml schema one extends the other but in java Integer does not extend
>> Long. I don't know if its truly relevant to your question but it is an
>> issue that i had.
> OK - I think this means that:
> 1 - we want to walk the inheritance and "cache" the results - i.e.
> flatten it out. I think that we should save the provenance of each
> attribute though - in case we ever need to to access the supertype
Yup, good away of phrasing it, "flatten out". I agree, we can easily
keep some information around about the types which flag them as
> 2 - we should NOT treat xml or java bindings as "the truth" - both are
> imperfect mappings of the underlying object model. We could probably
> make java match it - but would have to read the UML directly to do that,
> which we dont contemplate.
> 3. Many supertypes will be abstract and will rely on an implementing
> subtype declaring a concrete implementation.
> So - we need to bind attribute declarations to java objects in a lazy
> way - and throw an informative error if an attribute cannot be bound to
> a java class.
This hits on a key issue, one of validation. A lot of code in the old
models dies when you try to do this, set an attribute value which does
not match its binding. Jody has put it well many times, the need to have
"bad data" around. I think validation should be something the occurs
when it is asked for, like when data is being sent to a datastore or
> we should have default bindings, plug-in defined additional bindings
> and mapping-controlled bindings to cope. Default (what geoserver does)
> and mapping-controlled bindings the priority.
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>> Geotools-devel mailing list
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> Geotools-devel mailing list
The Open Planning Project