Hi Andrea,
some comments inline
> Citing from my review:
>
> "The whole model makes it explicit that when you're asking for a value,
> you don't get one, but a Property instead. The first reaction is, why
> would I need to get metadata along with data, isn't the feature model
> enough?
I feel your pain and guess this very question is perhaps the most
controversial aspect of the model, yet I think it has a worthwile rationale.
I'm going to try, off the top of my head, to explain it both from the
theorethical and practical viewpoints.
Theorethical:
The Feature Model intends to define a whole typing system to represent some
such of abstractions in a OO way, as it tries to mimic the OGC's General
Feature Model. As such, it needs to be sufficient enough as to model:
- a Class (AttributeType): which has a (scoped) name, an inheritance
relationship, an a value domain, which is a set of properties and their
cardinalities when the type models an object, or a range of values (given by
the bound java type and its restrictions) when the type models a primitive
entity, such as a timeperiod, a string, etc.
- a Class' property (AttributeDescriptor): which for each of the properties of
a class, captures the property name, the allowable content type of that
property, and the allowable occurrences of it.
- an Instance of a given type (Attribute): note for the typing system to be
complete, we _need_ to control what an instance of a given property is. It is
not enough to deal with the bound java type even for atomic types, as the
bound java types are just the ultimate primitive value, but has no
backpointer to its actual type definition in FM terms (in java you would use
instanceof to know if a property is of a given type, here you need
Attribute.getType() to access the defining type of an instance value).
So I wonder a pure instance of a given type would just need a pointer to its
type, in the same way an instance of java.lang.Integer has a pointer to its
class. The instance itself doesn't need to know the name of the variable
holding it, nor how many instances may be held in that variable, nor if that
variable is allowed to be assigned to a null value, which is exactly what
Attribute.getDescriptor() does. That's a matter for the context where that
instance is being used...
So the answer to your question:
"The whole model makes it explicit that when you're asking for a value,
you don't get one, but a Property instead. The first reaction is, why
would I need to get metadata along with data, isn't the feature model
enough?"
is Property is not metadata, it is actually a value object as per the type
system defined by the Feature Model.
Practical:
So... why the heck I still need to get a List<Property> when asking for
myFeatureInstance.get("foo") and I can't just get a list of Strings,
Integers, Geometries, etc?!?!?
Because "foo" is the name of a property of the type myFeatureInstance belongs
to (i.e. the name of an AttributeDescripor), the type of that property (say,
BarType) might well be... abstract! and you can't instantiate an abstract
type. Even if it is not abstract, the actual instances for that property
you're getting might be of a combination of subtypes of BarType....
And beleave me, sooner or later you'll want to know what the exact type of
each of those property instances are... whether because you need to encode
them to gml, or you want to present them in a tree view in udig... you'll
need to know the actual type of each instance because if not, you won't be
able to work with the nested properties of each one, because they're defined
in the type, and we saw you need to carry on the type with the instance in
the same way java.lang.Integer does through its getClass() method.
All that said, I don't think it would have been possible to work on the
complex features modules without such information at hand, but as I find I'm
ranting too much I'll leave it by now.
> The javadoc does not tell, but ComplexFeature.getValue() is
> returning a collection and not a list, so no ordering is implied.
Ah.. because property ordering is a matter of xml, not the General Feature
Model, nor the Java typing system. I'm pretty sure that was Bryce's pressure
to use Collection, separate concerns and keep thinkg as OO as possible.
> Rewording this, using List instead of collection in FeatureType
> would allow Feature to return the attribute values right away instead of
> wrapping them into Property objects.
Say you return list.. list of what? of a mixture of Integer, String, Geometry,
etc?
Say you have a FeatureType with the following properties:
- name:String[0..N]
- description:String[0..1]
- location:Point[0..1]
The you as feature.getValue() and get the list ["s1", "s2", "s3", POINT(0 0)]
how do you know if "s3" is the value of the attribute "description" or not?
That's why Property represents an instance on this model, not metadata.
Now, say Property has a pointer to the type, but not to the descriptor. So you
get the following list:
[ ["s1":String] , ["s2":String], ["s3":String], [POINT(0 0):Point] ]
same question.
But if Property has a pointer to the PropertyDescriptor:
[ [name:"s1"] , [name:"s2"], [description:"s3"], [POINT(0 0):Point] ]
now you *know* s1 and s2 are the values of the name property, and s3 the one
of the description property. Go and encode them to gml happily
ok, /rant.
Cheers,
Gabriel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
