[Geotools-devel] Yeah - another review of the Feature Model

[Jody G. <jga...@re...>]

David Zwiers wrote:

> http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Proposal
> Responces to this link.
>
> First, thanks for forwarding this link ... it's got alot of 
> interesting information relevant to GT :).

Yep. I try to move the decisions into code, but I am keeping all the 
discussion around just incase. I am afraid it does not do anyone any 
favours who is just wanting to know what the decisions *are*.

> I'll add my comments below, in the order they come to me (so not 
> ordered by importance).

Np. Not a lot of time so I will just answer until my maven build 
finishes (working on oracle today - I hope).

>   - Name: 'Complex' can we think about 'ComplexAttribute'  ... similar 
> to 'GeometryAttribute' or something else here, cause it's already an 
> overused name.

Fair enough - I was going short-is-sweet and focused on the design right 
now. Lets consider:
- ComplexAttribute - is not the best, as it may stand on its own
- ComplexEntity - better
- Entity - okay, short, but may confuse people - I at least like the 
conitation that their are no methods
- Struct - already taken by JDBC and a little bit "C"ish
- Feature - (but just have no geometry) - not the happiest with this but 
it would work, and may be worthwhile to cut down on number of classes

>  - Name: 'Node' is worse ... but it seems to be in Geoapi ...

No - I made it up. I was just trying to communicate that we had an 
ordering, the ordering was defined into clusters (of sequence, choice or 
all) and the "leafs" actually referred over to the type information.  
The point being that for "simple content" the order would be a Sequence 
of leafs, very direct and uncomplicated. But the more advanced stuff is 
possible. I went through this with Brent in one of the IRC chats. 
Complete with ASCII art (not that it helps).

So lets consider:
- Schema/Node - yeah I don't really like it either
- Schema/Leaf - even worse (it is fall however)
- Order/Entry - not bad, possibility of confusion with Map.Entry.

Perhaps you have a good idea?

>   - I am VERY concerned over the way in which the Schema object is 
> either used or named in GeoAPI. The idea of linking a grab bag of type 
> definition to a single type and attempting to get an association out 
> is mind boogling (based on the XML schema defintion). Since we are 
> talking GML here ... we still have this notion of a Schema, but what I 
> see here is quite different. I think a good naming compromise would be 
> to leave the method names alone, as that refers to the data's schema 
> (in the conceptual sense), but rename the class to represent this. 
> Maybe FeatureSchema? or AttributeSchema?

Sorry dave I did not follow the first part of that. Itself a good 
argument for not using the name "Schema" - as it confuses conversation 
with respect to GML.
- FeatureSchema - not bad, we do want it associated with any complex content
- ComplexSchema - bad
- EntitySchema - okay

You do understand that the schema forms a tree (just like a regex). The 
nodes in the tree represent types, like characters in a regex.

>   - The SchemaFactory interface methods do cause some concern, as I 
> cannot identify my instance in anyway (QNAME, name, namespace, id ...)
>  - FeatureType.isNilable() - Spelling mistake
>  - ComplexType.types() naming again ... the javadocs are a bit fuzzy 
> here, but is this the idea of children ... just with another (posibly 
> more confusing) name?

This represents a breadth first walk of the "FeatureSchema" recording 
all the Types.

>  - CompleType.type(String) ... has undefined behaviour since you 
> Identify the type with a generic name.

Type has a helper method called name() that accesses the last part of 
the GenricName, the method finds the first entry with the matching 
name.  The method is only their to help.
Would it help if we cut out the helper methods for now? I would hate to 
confuse the data model we are trying to capture with ease of use 
requirements.

>   - FeatureCollectionType.getMemberType() ... isn't this returning a 
> collection? getMemberTypes() (plural).

This is a mistake, it should return the schema of the allowed members. 
The schema may be a choice - if multiple kinds of members are allowed.

Hrm - wonder if we could use the word "Kind", as an alternative to 
'Type" and "Descriptor" - nope it is pretty lame.

>   - There is an inconsistency between the identification of a Type and 
> an Attribute. Attribute has an 'id' string while Type has a GenericName
>    This may be a result of mapping the type onto the attribute, but I 
> do not believe this will always be the case (GML schemas break this 
> regularily).

There should not be an inconsistency, name() is only a short cut for the 
last section of the GenericName. It is my intention that people use the 
real AttributeType for lookup as often as possible.

>   - Complex.get(String name) returns an Object. This method falls 
> short for two reasons, the GenericName issue above, and the posibility 
> of multiplicity.This is a HUGE INCONSISTENCY in your model. The schema 
> allows for this, but I do not see any way for me to access the data 
> described.

Once again this is a helper method, it is defined to return the first 
match for the name. Where name is the last section of the generic name.  
Programmers without simple content should use the actual AttributeType.

>   - Restriction ... These are identifieable, have inheritance, and a 
> structure. This is a step backwards as far as GT is concerned ... I 
> cannot encode SQL from this, need I say more?

I have tried to move back to the use of Filter. The "facets" are 
associated with a Type, and thus have inheritance. Can you encode SQL 
from that?

> Well, I'm tired ... stoping reading for now. Jody / Gabriel. Can you 
> please respond the the more substantive issues in Code. I think 
> writing Java code to illustrate some of these concern may help 
> understand them.

I think that process is already underway, Gabriel I think is booked this 
week, and am busy with Justin's last week.
Lets take this up next week as time permits.

Jody