Hi all,
I started writing this message convinced that there was a major flaw in the
feature model. Surprisingly it seems Jody/Bryce noticed it last week and put
AttributeDescriptor.getName() in place. It didn't existed yet. So I'm still
blaming myself about not beeing up to date with all the geoapi work done in
last weeks.
Anyway, I talked to Justin and we both agree that it could be the time to
engage for such a wide and worthy change.
Let me explain it. This explanation pretends to be short and simple, but you
can still blame me if I'm missing something too basic.
It seems we like to think of the FM as a dynamic typing system. That's good.
A typing system should be able of defining Types, which defines a value
space, and variables, which among other things holds a reference to instances
of that types.
Among other things means, as you know:
- name
- type
- scope
- value
(yeah, types often defines operations too, given the last emails on the list
from Bryce and co, looks like we'll need them too)
So, all typing systems we know match that statements, even xml schema...
except ours (till now).
WE DIDN'T HAD VARIABLES!, only types..
Before the new FM, we had FeatureTypes and AttributeTypes. But since we used
to be "simple",it wasn't much a headache. Every time we defined a feature
type's attribute, we created an AttributeType, because we didn't had a way of
defining an attribute with a name, a type, a scope, and a value. We only had
a AttributeTypes, they holded its values, so type and variable was all mixed
up.
It was like if a java class was tight to its instances, so if you had a
FeatureType with two string attributes, "name" and "description", they
actually was two different "classes", not to variables of class "string".
Furthermore, we made Feature and AbstractFeatureType the same thing, when
actually Feature is a generic attribute (variable) that may refer to any
AbstractFeatureType subclass.
Now, supporting complex features means a we need to really support type reuse,
like an AttributeType being used by attributes of various FeatureTypes.
All that said will appear obvious to many of you, so my intention is really
making sure AttributeDescriptor.getName() as added exactly for that purpose,
since it will be perhaps the most wide change over the geotools codebase.
Jody?
regards,
Gabriel
PS: Here is my chatting with Justin:
hey, do you know if AttributeDescriptor.getName() was added recently?
Justin Deoliveira: hmm, not sure, let me check
I guess it would, or I'm so stupid didn't seen it before. I was writing an
extensive message about a major flaw on our FM, about it not being a typing
system, since AttributeDescriptor having no name means it couldn't be seen as
a "variable", which forces us to do nasty things as Feature extends
AbstractFeatureType, which is really nasty, since "Feature" is just the name
of a widely known AttributeDescriptor, NOT a type
that fact, historically forces us to not being able to actually reusing types
Am I explaining it correctly?
Justin Deoliveira: kind of, you will have to excuse me i am stilling learning
the model
Justin Deoliveira: are you going to send email? this might be one for jody
yeah, but need to know when getName was added, don't know how to check it on
the CVS repo (never learned enough CVS)
Justin Deoliveira: i am not too sure either,
checking NodeImpl instead
ok, svn blame says you added getName() to NodeImpl, that means Jody figured it
out at time (at time meaning before its too late)
and added it to geoapi
Justin Deoliveira: hmm, yeah to be honest i was just doing things to get all
this to compile
Justin Deoliveira: there are lots of pending changes that jody made that will
break us
yeah, I know exactly what that means, kind of nightmare
now we have a challenge: people should start using
AttributeDescriptor.getName() for their attribute names, and start subtyping
innecesarily
Justin Deoliveira: what do you mean subtyping innecesaroly
Justin Deoliveira: ?
I mean doing things like Feature extending AbstractFeatureType, when they're
completely unrelated things
Feature is an AttributeDescriptor, AbstractFeatureType is a type
Justin Deoliveira: ok, i think i am starting to understand
aka, AttributeDescriptor is a variable, it has a name, scope (namespace), type
and value
AttributeType is a type definition, it restricts a value space (and
potentially defines operations over that type)
in java the equivalence is obvious
in xml schema, AttributeDescriptor is an <element>, AttributeType a
<simpleType> or a <complexType>
the only missing thing I guess is moving isNillable() from AttributeType to
AttributeDescriptor
Justin Deoliveira: i think that jody may have done some of this, like i said i
havent been able to use his new version of the model
Justin Deoliveira: since prioroty has been to get geoserver spitting out
something
Justin Deoliveira: is this a blockign issue for us?
that's right, and having AttributeDescriptor.getName() is one of the things
that will allow us to achieve that goal
mmm... not sure, let me put an example:
Justin Deoliveira: cool
your datastore is creating a FeatureType from a database table, that has
columns NAME String, GEOM Point
what we historically do is creating a featuretype with two attribute types:
NAME extends String, and GEOM extends PointType
when they should just be AttributeDescriptors with names "NAME" and "GEOM" and
types "String" and "Point" respectively
the same case than making Feature extending AbstractFeatureType
Justin Deoliveira: ok i understand now
Justin Deoliveira: one sec, let me check jody's latest version and see if
Descriptors can have names?
not Descriptors, just AttributeDescriptor
Justin Deoliveira: oh ok
for example: AttributeDescriptor relates to an xml schema "element", but other
descriptors relates to sequence, all, choice, etc
Justin Deoliveira: it looks like it was just added
Justin Deoliveira: its the last method on the interface
Justin Deoliveira: although its already there on the old version as well?
Justin Deoliveira: hmm, i think i am confused
that's why when, for example, we encode a feature collection in gml, we use
the attribute's type name as element names. The nasty thing with these is
that we couldn't define two FeatureType attributes with different names but
the same type, or even reusing types among different FeatureTypes
Justin Deoliveira: ok i think i understand
Justin Deoliveira: if i am correct, its like the type is tied to the intsance
when it sholdn't be
yes
ok, I'll send the email and attach this conversation if you agree
Justin Deoliveira: yup sounds good
may be Jody/Bryce will bring up more light
I know we're short of time, but may be its our only chance of fixing this
flow. It may be even be acceptable to discuss a bit more and apply after this
deadline?
or start using AttributeDescriptor.getName() incrementally, since its already
there
for example in the gml 3.1.1 encoding needed now
Justin Deoliveira: yeah, that could work
Justin Deoliveira: so what exactly does this prevent us from doing at the
moment
Justin Deoliveira: like should I still be able to get geoserver up and running
serving up complex content?
at least mapping for some of the more complicated Rob's use cases, where type
reusing is extensively applied
but now worries: the thing to do would be to use AttributeDescriptor.getName
in Complex DataStore, and in the gml encoding
(typo: now worries == not worry (not so much))
Justin Deoliveira: haha
Justin Deoliveira: ok, so lets send the email hopefully here back and rectify,
but for now i am going to whip up a http test for you to diagnose
yeah, sure. ok, thanks for your attention
Justin Deoliveira: thank you for making it clear
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90