[EMAIL PROTECTED] wrote:
> Heads up x2
>
> You are probably not going to get a geoserver branch; everyone is doing 
> everything they can to slow down and work together (a branch runs counter to 
> that - it allows you to move quickly but alone).
>
>   
Agred It would be better not to be on a branch, and Gabriel thinks it 
will be possible to exploit plug-ins on the trunk.  This would be ideal 
from my perspective, and allow me to chase further resources to test, 
and support Oracle data store.
> Justin perhaps it would be good if you outlined the conditions under which 
> you 
> would allow a branch to proceed? I am thinking three weeks max; specific RnD 
> goal; and a plan to bring the work home (even if the work is just a report).
>
> I am sure GeoTools would love having you whip "trunk" into shape but please 
> keep the GeoServer codebase in mind as well.
>
> On a related note Rob I would like to bounce a class diagram off you
bounce away
>  on what 
> you think the configuration needs of a "real" GeoServer is (from your email I 
> understand that includes XSD files provided by the end user; I can surmise 
> that it include a declaritive "application profile" (saying if things like if 
> the GetInfo opperation is turned on or not; and that is where I start to slow 
> down - 

> on your branch in the past there was a "mapping" step that I would like 
> to hear you talk about ...
This mapping had multiple functions (poor separation of concerns 
possibly, but always a hack). The interesting ones are:

1) Augment the "understanding" of the target schema by mapping 
particular data types to particular attributes (using Xpath).  This is 
actually quite interesting, as in many cases "profiles" will restrict 
generalised schemas to work with specific data types. (see type 
injection discussions). i imagine this will be controlled in the near 
future by adding schematron (Xpath assertions) to the XSD annotations.

2) Map the output of the simple "surrogate" datastore to the target 
FeatureType (derived from the target schema) schema

3) Control the "report writer" style mapping of multiple rows into 
multi-valued properties.

An interesting aspect is the decoupling of reusable data stores from the 
concept of supported FeatureTypes.  It would be nice to have a profiling 
mechanism to, on a tpye by type basis, control what is exposed.  This 
would allow us to do some funcky things - including creating surrogate 
FeatureTypes that we never actually expose via WFS.
Also, turning WFS/WCS/WMS on/off on a case by case basis.

I also want to have specific metadata overrides for a FeatureType for 
each service binding - in particular the ability of the service to 
advertise what profiles it supports is service type specific. 

>  don't worry about it making detailed sense I just 
> need to hear what kind of language you use as I am trying to understand the 
> problem).
>
> Cheers,
> Jody
>   



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to