Opps : I am mixing up issues here - sorry, Ben was talking about the WFS and other OGC schemas.
This is the same issue for GML: internally we use the real location and a cached copy - IMHO we should always do this - and promote the need for clients to do the same otherwise things will break somewhere. (you cant use GML without a local cache and a catalog IMHO). I would suggest equirements: *) All Geoserver schema use (e.g. configuration, validation, parsing) needs to use local caches consistently *) Good documentation to inform users. *) "truth in advertising" - give clients an opportunity to use _thier_ caches by using the canonical URLs Rob On Tue, Dec 15, 2009 at 10:35 AM, Chris Holmes <[email protected]> wrote: > We should check that the OGC is ok with this. I think originally we moved > it to serving it up ourselves since the OGC one wasn't reliable. Or maybe > they weren't even serving it at all? We've got a decently big user base, so > we might increase the traffic there not insignificantly. I'm not opposed to > it, but this is the first complaint we've got about it, and I'm not > convinced that there's going to be much of a performance gain for many > clients. And I'm generally of 'if it's not broke don't fix it'. > > Rob Atkinson wrote: >> >> It should should be default ("truth in advertising") >> >> app-schema always uses the correct url for the configured schema >> anonymous schema always uses a introspective data-store derived schema >> from the WFS >> >> clients using XML, a web technology, without a web connection need to >> use the standard XML archiecture - in this case OASIS catalogs. >> >> This is simpler than using a flag or adding burden on admins to get it >> right IMHO. >> >> Rob >> >> On Tue, Dec 15, 2009 at 2:39 AM, Justin Deoliveira <[email protected]> >> wrote: >>> >>> Hi Ben, >>> >>> This has come up a few times in the past and the general idea is that >>> using a canonical url would require wfs clients to have an internet >>> connection in order to parse a wfs response. Which was decided would be >>> too restricting. >>> >>> What probably should do is add some sort of flag to allow server admins >>> to control this. >>> >>> -Justin >>> >>> Ben Caradoc-Davies wrote: >>>> >>>> Is there any reason why WFS responses include a WFS schemaLocation URL >>>> that points back to the server, and not the canonical location? >>>> >>>> At the moment a WFS 1.1.0 response includes this: >>>> xsi:schemaLocation="http://www.opengis.net/wfs >>>> http://localhost:80/geoserver/schemas/wfs/1.1.0/wfs.xsd [...]" >>>> >>>> I would prefer the canonical location: >>>> xsi:schemaLocation="http://www.opengis.net/wfs >>>> http://schemas.opengis.net/wfs/1.1.0/wfs.xsd [...]" >>>> >>>> The canonical location is more likely to be cached by a validating >>>> client, and can be easily recognised as a WFS 1.1 response without >>>> having to fetch and parse the server's copy, which may or may not be the >>>> same. >>>> >>>> Kind regards, >>>> >>> -- >>> Justin Deoliveira >>> OpenGeo - http://opengeo.org >>> Enterprise support for open source geospatial. >>> >>> >>> ------------------------------------------------------------------------------ >>> Return on Information: >>> Google Enterprise Search pays you back >>> Get the facts. >>> http://p.sf.net/sfu/google-dev2dev >>> _______________________________________________ >>> Geoserver-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- > Chris Holmes > OpenGeo - http://opengeo.org > Expert service straight from the developers. > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
