well, for a start its great to see the issue being debated before finalisation of code :-)
I'm not over the intricacies of the beast to be honest, just providing a "sanity check". One thing I'd point out - namespaces do not exist to disambiguate the feature type on the server - they exist to disambiguate it once it leaves the safety of the server - in the outside world. If the feature type names do not mean anything - just call them all foo:1 foo:2 foo:3 - there is simply no need to have disambiguation around arbitrary names. The current linkage between WMS layer name anf featuretype name is a convenient default - but is purely arbitrary and should be able to be overridden. Eg hat about a feature type road, and WMS layers road250K road100K road25K, in a layer group road_anyscale? IMHO What we're talking about is not the information model - its UI workflow optimisation for simple cases. Its the bleed-through of this concern to the resource design that caused such confusion. so - what is a dataAccess - semantically? is it a featuretype, or is an adaptor to allow common optimisation of access of a set of feature types, or is it a connection - the right to access a set of resources? I've always had a problem with the declaration of namespaces and database connection parameters in the same file ;-) Perhaps someone can throw up a formal model of this configuration metadata - I find text descriptions too prone to misinterpreation. Rob On Wed, Jun 17, 2009 at 3:15 PM, Gabriel Roldan<grol...@opengeo.org> wrote: > Ben Caradoc-Davies wrote: >> Andrea Aime wrote: >>> But isn't the namespace a publishing property, and >>> so something that should be set at the layer >>> level? >> >> Some feature types get their namespaces glued on at publishing time. >> Some have their namespace as an intrinsic property; for example, >> app-schema feature types. >> >> You think you have problems: a DataAccess can provide feature types with >> qualified names in different namespaces. See DataAccess: "List<Name> >> getNames()". Given that a workspace and thus data store are named by the >> namespace prefix, if you want multiple namespaces from a single >> DataAccess, you are stuffed. For example, I can create a single >> DataAccess that returns a gsml:MappedFeature and a sa:SamplingPoint. In >> which workspace can this live? The workaround is to Not Do That Then, >> and instead proliferate DataAccesses, one per feature type. The catalog >> implementation prevents a legitimate use of the DataAccess API. See >> GEOS-3042. > It does now, but it doesn't need to when the resource/publish split > becomes real. > To augment the app-schema case, there's also the cascaded WFS case. If > you're cascading featuretype prefix:Road from a wfs and you need to > rename it to anotherprefix:Road then you're not just cascading. > But when the resource/publish split it should be heaven. > First, namespace (as per the ones registered in geoserver) stops being a > first class citizen to be means to ensure name uniqueness _only_ for > those DataAccesses whose feature types do not have an inherent > namespace. That is, they ensure name uniqueness at the datastore level, > namespace is passed as a DataAccess factory parameter to ensure name > uniqueness at the WFS entry point level. > Second, there's gonna be an even better separation of concerns. > Namespace is meaningless outside WFS. WCS and WMS do not really need > them to refer to a coverage or a wms layer. They will just refer to a > resource, which refers to a data store, which refers to a workspace. So > no name clash. You'll just need to be sure to _publish_ them with unique > "layer" names. Benefits of this are bound to imagination. Say you want > to publish the same resource twice in WMS, with different default > styles, different CRS's, or using different "definition filters" (common > case being a single roads type where you want to publish roads and > highways as different layers). > > But I have to admit after all this ranting, the original issue keeps > being confusing. Reason being there's not a perfect separation of > concerns between ResourceInfo and LayerInfo yet. In my mind, > ResourceInfo should the closest to the physical resource metadata as > possible. In the case of feature types, only the information that can be > obtained from the FeatureType, and hence in the UI plainly informative: > qualified name, native CRS, native bounds, etc. > LayerInfo should be all about publishing a resource: published CRS, > alias, lat/lon bbox, etc. > - Where does namespace fit? both places. In ResourceInfo it should be > immutable, even null. Then we should get rid of the namespace datastore > parameter. It is a band aid after all, no real API for it, just a > convention we injected into geotools for the good of geoserver pre-2.0 > :). But the empty namespace is a perfectly valid one in GeoTools. And > GeoServer could use that knowledge to infer whether a LayerInfo > referring to a ResourceInfo _needs_ to use an overriding namespace (if > the resource does not natively provide one), or _can_ use an overriding > namespace (just a convenience publishing option). > - are layernames gonna be qualified? for WFS, yes. For WCS/WMS, no need. > The lookup mecanism from a non qualified WMS layer name to it's > underlying resource is guaranteed since the layer has a direct reference > to the resource it's publishing. When you publish the layer just make > sure it's name is unique "profile/map" wise (aka, WMS entry point wise). > - what happens if I publish a layer with a different name than it's > resource? you're aliasing the resource. > - what happens if I change the published namespace for a resource? > you're aliasing the resource. > > This is how I see the resource/publish split is gonna give the benefits > with the least hassle. I may be missing important topics though. > Comments welcome. > > Gabriel >> > > > -- > Gabriel Roldan > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
