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.
> * AssociationType javadoc.
> We should have the notion of simple association in the javadoc
> as well... I mean, a business partner association is not
> aggregation and I may not be interested in making the spatial
> or temporal side of it explicit.
Fixed.
> Javadoc still uses first person ("I am treating the domain
> of the association type...").
> AssociationType.getRestrictions() is simply repeated, no
> extra info on it compared to the base class, same goes
> for isAbstract().
Removed.
> 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).
> * ComplexType
> In the javadoc, the bar property descriptor should report
> nillable == false.
Fixed.
>
> * 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.
> * PropertyDescriptor.
> Nullable or Nillable? I don't care, but let's use just one.
> A google search returns 220.000 nillable, 633.000 nullable.
> Nillable seems to come from xml schema, nullable is
> used in c# apparently.
Nillable it is ;-)
PropertyDescriptor.getName() says the value may be null in some
instances? what instances are those.
> * OperationType
> "exciting" should not have a place in javadocs... I guess
> this one still needs to be rewritten?
Yeah have a look now.
> * 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...
> * Attribute
> Since ComplexAttribute isA Attribute, saying that we use
> it to model simple data types is incorrect. You should say
> that simple data types should be held inside an Attribute
> instance, and that for complex attribute there are
> specific subclasses (note the change of direction in the
> implication, simple value -> attribute, but attribute
> does not imply simple value).
>
> * 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.
> About this thread
> --------------------------------------------------------------
>
> Wasn't FeatureCollection supposed to be removed from factories?
Done. Also made it not implement Feature. Left the getBounds() method.
> SimpleFeatureFactory.createSimpleFeatureCollection(...)
> is still there.
removed.
> One question about order. XML gives us an ordered representation
> of the properties. Does this mean that our implementation will
> use List internally to preserve that order when parsing data?
Tough call,
> About the destiny of FeatureCollection, I agree with ISO,
> let it be a data access tool, and forget about them being features.
Cheers,
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
