Jody wrote: > It is on my email back log of important email that takes a long time to > read :-(
OK, understood. I will try to make future mails shorter. Its just that I fear if I express myself too compact I will get misunderstood. > > 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 ... > > > Please provide Jira Issues and we will fix it. Huh? There's nothing to "fix". > > 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. [...] > > > I don't think that is possible - we are trying to track a standard so we > can work with predefined styles. We have already made allowances for > those working on extending the standards (but we have tried to make it > clear at an interface level what can be expected to work across systems). As noted in my original mail, I agree that specificiation compliance must already made clear a the interface level, e.g. - Interface A has a note: This is part of OGC specification XYZ. - Interface B has a note: This is NOT part of an OGC specification. At least the former is already done in GeoAPI. I still believe that adding other interfaces and superinterfaces "around" the interfaces defined in the spec is technically possible. If everybody likes this approach is another question. > So far I see no reason to extend Filter in the same way: > - ProperyName is extensible enough to work against a range of content > (especially with XPath) Agreed. > - Function is extensible enough to allow additional functionality > (questionable if that still can work across systems) Working with functions is something I have to explore more deeply before drawing any further conclusions. > > 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. > > > I tried doing this as an experiment (it was spike/expr) and I loved the > results. [...] However I was wrong. > > The Filter "scripting language" is aggressively untyped - it almost > works like REXX in that almost everything could boil down to a String. > And then you need to build up that type information again during > evaluation. Makes sense for a script that is supposed to run between > machines. What exactly did you try and why exactly did this fail? Sorry, I just cannot imagine that specifying the output type of an expression would collide with the "scripting language" approach. As long as each expression accepts any object as input (and is able to convert any object to whatever is internally needed) it would still be possible to concatenate ANY two expressions with each other if just the implementations can cope with any required conversions. (Which they obviously can already.) Actually, to make it 100% clear: Even if GeoAPI provided typed interfaces, GeoTools would still be able to deliver untyped (Java 1.4 style) implementations just the same way as it was done for the referencing API, so in the most simple case nothing would have to be changed on the GeoTools side of things. -- 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
