Thread: [Geotools-devel] Why we don't want ft to extend at.

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

From IanS - this argument definitely persuaded me.  Sorry I haven't 
Status: O

sounded in earlier, but yeah, don't do ft extends at.

Chris

-- 

---------- Forwarded message ----------
Date: Tue, 8 Mar 2005 10:32:34 -0700
From: Ian Schneider <Ian...@ar...>
To: Chris Holmes <ch...@op...>
Subject: Re: [Geotools-devel] features-exp2 update

On Thursday 03 March 2005 07:13 pm, Chris Holmes wrote:

Hi Chris,
I wanted to get back to you on this earlier, but been pretty busy. 

> For this round we just had FeatureType extend AttributeType,

I understand that this seems like a good thing to do, but I will argue that it 
is wrong. Ok:

Think about a features and attributes as java classes and fields. An 
AttributeType represents a field declarartion in a java class. It has a name, 
it has a type, and in addition, the restrictions on its data (this is 
actually analagous to a setter which throws an exception if the value is bad 
or a getter which returns a default value if none is set). A FeatureType can 
be seen as a java class with a number of field declarations. It also has a 
name, could be extended from another class, and could contain additional 
meta-data. In java, a Field implements Member and a class implements Member, 
but a Class does not extend Field. This is not my only argument for not 
having FeatureType extend AttributeType.

Lets look at some example GML (the old cambridge example was on hand) :

This is a FeatureType which extends AbstractFeatureType and adds the 
additional attribute of centerLineOf.
  <complexType name="RiverType">
    <complexContent>
      <extension base="gml:AbstractFeatureType">
        <sequence>
          <element ref="gml:centerLineOf"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

This is an AttributeType. Its name is River, and its type is a Feature, more 
specifically, a River.
  <element name="River" type="ex:RiverType" 
    substitutionGroup="ex:_CityFeature"/>

Now lets say there was an additional type (and I don't know if my schema is 
proper, but the idea is that the Basin contains more than 1 Rivers.
  <complexType name="Basin">
    <complexContent>
      <extension base="gml:AbstractFeatureType">
        <sequence>
          <element minOccurs="1" ref="ex:River"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

And another type (a land area which drains into a river segment)
  <complexType name="Reach">
    <complexContent>
      <extension base="gml:Basin">
        <sequence>
          <element ref="gml:Polygon"/>
          <element minOccurs="1" maxOccurs="1" ref="ex:River"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

So if FeatureType extends AttributeType, there is only one definition of the 
actual type River, but two differing definitions of AttributeTypes which 
reference River. The ideal way to represent this an AttributeType subclass 
whose "type" is a FeatureType - more specifically, a River.

The point being that FeatureType, if it extends AttributeType, performs two 
roles, one of being a type definition of a complex entity, the other being a 
reference definition to that complex entity. Ideally, you would have a entity 
definition and then one or more differing definitions of references to that 
entity.

> and rethought 
> what the AttributeType methods meant in the context of a FeatureType,
> leading to decisions like deprecating getTypeName in favor of the getName
> method of AttributeType.  

This is further proof that extending AttributeType is wrong.

> We then also split out the AttributeType 
> hierarchy from hidden in DefaultFeatureType into the feature/types/
> directory.  Like NumericAttributeType and TextualAttributeType.  These
> ended up being classes - the point is to show people that you can actually
> implement your own AttributeTypes.

This is good and definately needed to support all of the data types. The other 
thing I'd really love to see is more flexability with types. Our current 
framework is very similar to geotools - we have AttributeType and EntityType. 
The main difference is that we also have Attribute, which represents instance 
data (IntegerAttribute, DoubleAttribute, etc.) and geotools uses normal java 
objects. I will not argue that geotools should wrap data values in its own 
classes, but it does have its advantages. For instance, all of our Attribute 
subtypes can be converted to and from strings. This would be possible in 
geotools by having the Attribute subtypes providing this functionality. One 
problem I noticed in geotools is that data is sometimes to strongly typed - 
this arises in shapefile because arcinfo is(was?) so weakly typed in its 
enforcement of values. An example of this extended functionality would be to 
allow Strings to be used as Numbers and vice-versa.

>
> And again most are in the types directory.  The point of all this is to
> get featureType to extend attributeType, so that we can use them nested,
> and support choices, multiplicity, and sets.

Again, the proper thing to do is define a FeatureAttributeType or something 
along those lines.

A final point I wanted to touch on is the XPath stuff. I don't remember if you 
mentioned a plan for its implementation, but I will strongly argue that 
Feature should know nothing about XPath, but only support the getting and 
setting of its own direct children attributes. The full XPath support would 
come from an external class. The reasons for this are two 1) Making Feature 
know about XPath is like making a web page developer know about google and 
its internals - its not right to enforce the search process on the data, but 
right to force the data to allow searching, and 2) XPath will be more 
efficient if exectued externally. Example - DOM apis. One uses the XPath 
object to 'compile' a query which can be resused over and over again. Sure, a 
Feature could internally delegate the search to an XPath object, but again, 
this makes the data know about the searching mechanism.

Hopefully this was all understandable (I did kinda just rattle it off) and I 
understand that I haven't been an active developer of late, so please don't 
hesitate to ask any questions or continue this discussion.

On a good note, I finally figured out how to get subversion access (and I will 
set up things here to allow Bryce Nordgren(?) access as well. If you have his 
email, could you send that to me as I seemed to have deleted it.

Regards,
Ian

Thread: [Geotools-devel] Why we don't want ft to extend at.

Toolkit for working with and mapping geospatial data

geotools-devel