Sorry for bothering again.
Has anyone read my mail from Mon, 19. Feb 2007? There wasn't any feedback.
Among others I asked about your opinion to following three suggestions:
1. GeoAPI imho does not need not follow the OGC (filter) specification in
detail and exclusively in order to fulfil the spefication. So that ...
2. ... it would be possible that the existing expression API became embedded
into a more generic expression API with a scope wider than "just" GIS. GeoAPI
expressions are (if I understand it correctly) just a special case of
expressions with one input argument where the input argument is an object
having attributes ... like features).
3. That the GeoAPI expression API use gernics (typing) and classes that store
the expression's output type and required input values, so that each expression
can also be used comfortably in type save environments without loosing the
flexibility that they currently have.
4. Would it be possible to give names to "Add", "Subtract" a.s.o. that give at
least a hint that these classes have something to do with expressions.
I would really like to get some feedback on this.
On Mon, 19. Feb 2007 I wrote:
[...]
> Can the GeoAPI fulfil my requirements after some changes?
>
> To 1. above (Following the spec):
> I tend to have the opinion that implementing a specification in Java
> language does NOT necessary mean to copy classes, names and (important in this
> respect) hierarchies exactly 1:1. I share the opinion, that a specification
> is fulfilled if its requirements are fulfilled by a subset of the
> corresponding Java API and implementations and if these provide the required
> functionality. 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.)
>
> To 2. above (Generic API for usage outside GIS scope):
> This is a bit tricky to do, but ihmo possible. Specifically:
>
> a) The OGC spec clearly defines some interfaces, some of which
> should/might be extended, others where this does not make much sense. I
> believe
> GeoTools is free to relax this and allow free implementations and extensions
> like for nearly every "normal" API. If creating a new subinterface makes
> sense or not should be left to the programmer's opinion and to the question if
> the expression, when exported to XML, can be OGC conformal. ("Extend at own
> risk." ;-) )
>
> b) The OGC doesn't define that org.opengis.filter.expression.Expression
> might not actually be a special case of a more broader expression API.
> (That is:
> org.opengis.filter.expression.Expression
> extends some.other.package.GenericExpression (or whatever...)
> In my concept of expressions the "typical" OGC expression - taking a
> feature/graphics or any other bean-like input object - is actually a special
> case of a generic expression that may take any object as input, maybe
> something as simple as an Integer. Note that in GeoTools there is a big
> difference
> between what you CAN input and what you SHOULD input in order to get a
> reasonable result for. (Example: GeoAPI "PropertyName" theoretically allows
> you
> to give pass in any Object as input, but nobody would expect it to work
> when passing in a Number, or Color.)
> I'd like to make this more explicit, by making, f.e. the OGC
> "PropertyName" a subinterface (within this generic API) that clearly states
> implementations need only cope with objects having attributes. In this
> context you
> will hopefully understand my ideas about typing in the expression API (See
> point 3 below).
>
> d) In my concept of expressions they can be classified by what I'd call
> dimensionality analogous to one- and twodimensional functions in math. With
> this I refer to the number of their input arguments. And I do not make any
> distinctions between "input" and "parameters" as the GeoAPI "Function"
> interface does. (There isn't any difference, is there?) This means that the
> OGC "Literal" actally is a zero dimensional expression whereas the OGC
> "PropertyName" is a one dimensional 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.)
>
> To 3. above (Typed API):
> GeoTools is still 1.4, but GeoAPI is not! They have shown with the
> Referencing API that typing can be useful to avoid unnecessary casts and
> runtime
> class cast exceptions. Also, the OGC specifications are not in the way
> either. I cannot remember having read that an expression must be able to
> return
> a result as any class.
> 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?
>
> So, specifically what I'd like to see is
> - Every expression has an output type (Expression<O>)
> - Every expression can provide this output type and the required input
> types as classes for any non-typed environments (pre Java5)
> e.g. Class<O> getOutputClass();
> Class[] getInputClasses();
>
> Why should I need this? I have an example in my styling widget: There is
> an "expression registry" where all implementations are stored. Lets say, the
> user must create an expression for the line color. I ask the expression
> registry for all expressions that return colors. (E.g. constant color, color
> by mapping from values, color gradients derived from numerical values as in
> elevation maps) and then fetch corresponding UI elements for them.
> This certainly can be done without typing and even without an expression
> knowing its output class, but doing it above way it is cleaner, imho.
>
> ---
> Last but not least...
>
> - 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. (Sorry, I really
> dislike these names.)
> What about "AddCombinedExpression"? Even "AddExpression" is still better
> than "Add". (This wouldn't influence the XML representation and therefore
> would not influence conformity to OGC, would it?)
>
> OK, I hope I havn't missed anything and expressed myself clear enough.
>
> A am well aware that some people might prefer the current API and
> implementations "AS IS", but I felt it wouldn't harm to introduce my point of
> view
> and my suggestions. All in all I come to the conclusion that the expression
> API can be improved/extended considerably without loosing the OGC spec out
> of focus.
> Sorry for the rant. ;-)
--
Matthias Basler
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
