Andrea Aime wrote: >> 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... Yeah if we collapse the information we don't know where it comes from, also there is the usual matter of can we expect implementations to get the collapse logic right?
This is a common pattern you can see with properties as well, basically we only are describing the contributions made by this ComplexType. For the complete recipie describing what you need you are going to have to look at super and take into account multiplicity overrides, additional filters and so on. Right now: - EMF has both the EClass field contributions (ie the metadata model) and the complete list of fields (ie the processed model into a useful form). - We have just the metadata model, leaving processing the all the information in a utility class for now. > 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? Opps! not so fast. The goal here is to allow invalid data, you can make an implemenation that fails fast but there is no reason you have to. Just like with the processing of propreties above we left an isValid check for a utility class. >> 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? No meaning; I changed the java docs to say the min / max occurs was 0 (but forgot to mention it in the email). This min / max occurs did not used to be here (this is the consequence to bringing the structural information up into PropertyDescriptor). You can push the information back down into AttirbuteDescriptor and AssociationDescriptor if you think it would be more clear. > 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. Not sure I understand your example very well; I mostly view this as a way to "out" methods to the dynmaic type system that is the general feature model. For the operation used by coverages for sampling they get a single value (a Record actually) and the operation describes this result as a RecordType). There is supposed to be some intergration here (both Record and FeatureType are supposed to have MemberType - all these things extended Name and were really horrible. GeoTools includes a RecordType and I have never seen a use of it I respect from an interoptibility point of view - everyone stubs and/or returns null. >>> 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? I would guess that SimpleFeature would not be applicable then? Um "gml:name" is an odd case because "gml" is a prefix; the formal unambigous name would be bit longer and represented as a formal Name object right? >>> * Association >> 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 see nothing changed in the api thought. At the moment a user > accessing an association can still call both getValue() and getRelated(). I was explaining the API not changing it: - Association.getRelated() follows your association - Association.getValue() is the same as getRelated().getValue(). >>> * 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... Nice explaination thanks. If you found any of this email useful please tell me what is worth putting into the javadocs. Jody ------------------------------------------------------------------------- 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
