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
