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 ([EMAIL PROTECTED]) Axios Engineering (http://www.axios.es) Tel. +34 944 41 63 84 Fax. +34 944 41 64 90 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
