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
