> Yeah I get it; thinking .... so with that use case in mind publisher, 
> keywords, description and title would vanish? Or at least be optional 
> (reserved for a subclass?)
> ... I am still stuck requiring icon and type (even though it causes 
> friction). It is tempting to think of icon and type as describing the 
> format more than the service; but in practice it did not work out for me.
Again... type is something that belongs somewhere else... to where you 
are publishing data. The shapefile itself has no notation of a "feature 
type", so why should it be responsible for producing it.

I am still not getting the point of icon. Would it be some well known 
icon that we copy into the shapefile module? And just return it as need 
be? What if an app wants to use another icon? Does not seem to fit.

Also, a crazy idea (actually it was Chris's idea). Why not just make 
this a map or something and call it a day. That way formats can set the 
information they have, ignoring non-relevant stuff.

> 
> SERVICE       shapefile     database     wfs        wms
>       title                               x          x
>    keywords                               x          x
> description                               x          x
>   publisher                               x          x
>        type       x            x          x          x
>      source       x            x          x          x
>        icon       x            x          x          x
>    drm crap                               -          -
> 
> RESOURCE      shapefile     database     wfs        wms
>       title                               x          x
>    keywords                               x          x
> description                               x          x
>        name                               x          x
>      schema       x            x          x          x
>        icon       x            x          x          x
>      bounds       x            x          x          x
>         crs
> wgs84bounds       -            -          x          x
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 
> !DSPAM:4007,47aa593a248491961014482!
> 


-- 
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to