Re: [Geotools-devel] Expression API design thoughts

[Matthias B. <mat...@ea...>]

Hi Jody, all all,

thanks for you sensible answers. I will try to adress them. See below.

> We want a standard contract between client code (ie style) and server 
> code (data provider), we cannot do something open ended here as data 
> providers have different abilities.

Correct, and agreed. See my comment below for details.

> >Expressions are everywhere where there
> > are searches, selections, filters, mathematical functions and the like! > > GUIs for searches in bibliographic databases are a very neat example.
> >   
> You should look to the catalog specification for an example ...
> they define a double hit combo team of Query and QueryLanguage; they 
> also ship with a CQL as an example (ie. common query lanaguage text 
> format). The point is they left the door open for additional query 
> languages such as SFSQL and for "searches", "selections", "filters", 
> "mathematical functions"...

I will check the catalog spec.

> > 3. Jody described the GeoTools API to be like a scripting language.
> While this is clearly a feature in some places and for some people, my personal
> preference is clearly for a clearly typed API. .... snip ... The GeoAPI
> expressions API cannot currently deliver this.
> >   
> Mattias can we explore an ExpressionBuilder offline ... I think it will 
> meet both our needs.

Offline? You are welcome to visit me in Germany. :-)
Seriously: An Expression Builder is already one half of the way. You have this StyleBuilder class, which actually has some simple expression building facilities. Yes, I believe it to be a good idea!
The reason why I thing an expression builder alone is not sufficient is that I believe type safety should focus on the (Geo)API level. I just don't like an untyped interface, like, lets say "Stroke" where you find:

  Expression getColor();
  Expression getWidth();
  Expression getOpacity();
  Expression getLineJoin();
  ...

I would be very happy to work with interfaces like this on a style widget:

  Expression<String> getColor(); //(or <Color>, see below)
  Expression<Double> getWidth();
  Expression<Double> getOpacity();
  Expression<String> getLineJoin();
  ...

(BTW, handling colors as Strings is another thing I found bewildering. Sure, when exported to XML files they are stored as Strings, but when working on them in the program, handling Colors would be easier (although there would be the AWT vs. SWT conflict, which you circumvent in an elegant fashion by storing Colors as Strings. Anyway, not a problem for me...)

Of course the above is just a matter of liking/disliking, not a matter of missing functionality.

> > Clearly, the CURRENT GeoAPI expression API can not deliver what I need.
> >   
> I think this is by design; not all data sources have a good concept of 
> type. Also metadata system and query system is usually a poor trade so 
> one needs to be careful here.

Not sure I understand what you mean.

> > People wanting a "strictly conformal" use could simple restrict
> themselves to a subset of the interfaces and implementations. (We could use use
> tags to mark interfaces that exactly follow the specification in order to
> distinguish them from our extensions.)
> >   
> My approach has been to provide a Factory that is exactly limited in the 
> same way as the specification. I hope you find it is sufficient.

Sure, this makes it even easier for the people in question. Good idea.

> I am not worried about the XML use; I am worried about your contract 
> with other programmers. They are *only* going to know about the 
> published GeoAPI interfaces...
> Yes GeoTools can publish some extensions (and force their programmers to 
> make use of those extensions).
> 
> But we cannot really leave this door open for you the client programmer 
> (the API contract does not work in that direction).

Ah, I should have made it more clear that any "extension of the OGC specification" that I refer to is for "internal use" by developers in and with GeoAPI/GeoTools only .. or for contexts where OGC is not a topic at all.
My styling widget is an example of such "internal use". Within my styling widget I am free to do whatever I want... if only any created SLD styles can by exported to specification compliant SLD files.

>From a technical POV the problem for me is, that I (and Geotools) can create as many subinterfaces and implementations for GeoAPI interfaces as we want (for internal use!), but I cannot create an "internal" superinterface for an existing GeoAPI interface when I would like to have one.

> > To cut long stories short:
> >   I believe it would be possible to design a generic expression
> >   API in which the OGC expression API is merely a subset and has
> >   a structure that differs slightly from the current one WITHOUT
> >   losing any of its functionality or OGC conformity!
> > (I almost have a proof of concept.)
> >   
> And I am not sure that meets the goals of the GeoAPI project ... 
> inventing our own thing is not of interest.

On the one hand I feel a bit sorry about this, since it might lead me to "reinvent the wheel" if GeoAPI limits itself too much to specific specifications. On the other hand I agree that GeoAPI simply cannot define APIs for everything. (And for future specification changes it might become problematic if GeoAPI had own extensions that collided with these changes.) 
So in the end I have to agree.

> Allowing you to invent something; and negotiate a common 
> query language with a data provider is of interest.
> Then we can figure out what query langauges are 
> actually good; and possible
> standardize some ideas for broader use ...

I admit I have not much experience with query languages ... it just never occurred to me how close they are to expressions. Surely something to investigate for me.

> To cut a long story short ... if you make something will Postgres 
> support it? How about Oracle?

I have solutions for working on Oracle and Postgres alike. Others also have. But that's off topic. ;-)

> > Last but not least I believe that every implementation in GeoTools
> actually knows exactly what it will return. UniqueIntervalFunction always
> returns an Integer (slot number) for example.
> > Anything speaking against a typed expression API which I have
> overlooked?
> >   
> Reality:
> - in that you can run a string function on an Integer

Never doubted this after your first mail. But this is fine for me.

> - You cannot know the value of a PropertyName expression

Agreed, and I was well aware of this .. and, yes, I shouldn't have written "every implementation". So PropertyName could only be an Expression<?> and it would be necessary to work untyped in order to put a PropertyName somewhere where, lets say, an Expression<Integer> is needed. Not nice, but acceptable for me.

If you point is that a COMPLETELY type safe expression API is not possible then I agree. Doing it wherever possible would be my approach.


> > - Could you please consider renaming the "Add", "Subtract", "Multiply"
> and "Divide" interfaces to something that tells everybody on the first look
> that these things have something to do with expressions. 
>
> I like it can you make a Jira?

Done. 

Thanks again.
-- 
Matthias Basler
mat...@ea...