Jody Garnett ha scritto: > Hi Andrea - a more detailed response this time: >> * PropertyType.getRestrictions(): List<Filter>. >> Does this list include the parent restrictions? Would be nice so. > Afraid not - we need to consult getSuper().getRestrictions() as well.
Any specific reason for this? Ah, I guess to properly encode the restrictions in an XML schema we need to know on which elements of the hierarchy they have been placed... So the client code will either need: * a utility method somewhere to perform the check before setting the value * catch an exception when setting the value. Is the code supposed to be fail fast? How do we check a feature state is valid? >> If both Association and Attribute can be identified, can't >> we move that bit of metadata on PropertyType? > Good catch - I don't think associations can be identified. >> * AttributeType javadoc... ugly. > Fixed. I left List<Operation> out of it since we need feedback from the > coverage crew. It does look as if the GFM Operation and what coverage > has is compatible - both are ways to wrap up an invoke. Found a few > conflicts with Operation extending PropertyDescriptor (all about the > methods we pulled up). What's the meaning of Operation having multiplicity? Something like, the operation maps a coverage content, and given x and y, it returns the 7 bands values as an array of double, so multiplicity is min 7, max 7? I don't think you can do anything but an interactive pixel query with such a method thought, it's too inefficient for anything else. Access to big amounts of raster data must be optimized to the bone if you want it to perform decently, I think coverage people may just say "ok" for this kind of support, but then stay 1000km away from it in whatever real world implementation they do. >> * SimpleFeatureType >> "attributes are non qualified". Hum, what do we do with >> GML Feature attributes like gml:name? >> "the multiplicity of attributes is always assumed to be >> 1, ie, getMinOccurs() == 1 and getMaxOccurs() == 1." >> What, no nullable attributes anymore? We can't even >> represent a flat database table this way? > Nillable is seperate from multiplicity as I understand it ... the > attribute can still have a place in the list - the value just > happens to be null. Got it, but there were two questions here. The first one is still unanswered: "attributes are non qualified". Hum, what do we do with GML Feature attributes like gml:name? >> * Association >> Why not replace getRelated/setRelated with >> getValue(): Attribute, setValue(Attribute)? >> Would be more consistent with the rest of the API. > I think we are trying to set it up so people can smoothly use things > from the property interfaces > (so they can access the binding and value of a property regardless of if > it is an attribute or association). > > I personally would find this useful when working with an a feature > called "Edge" where one feature has the > start point as an Attribute and the other has a reference to this point > as an association. Of course my example is now troubling me - GML > represents that as a choice do they not? Allowing the startPoint > property to be either a association or a attribute... I see nothing changed in the api thought. At the moment a user accessing an association can still call both getValue() and getRelated(). >> * Feature >> getID() is basically unchaged from Attribute, maybe we >> should remove it. But we should state that a Feature >> is always identified somewhere, right? > I find these more specific javadocs to be useful. We do state that a > feature is identified - FeatureType.isIdentified() always returns true. > > Actually Andrea - is that the case? or is it just something stupid GML > inflicts on us? I think when editing new features we have exactly the > case where the fetures are not identified yet. Indeed, but that's not a structural thing. FeatureType.isIdentified() describe structure, not transient state. I guess if you want to say a Feature is not identified yet, getID() should return null? Or something like that... Ciao Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
