The major reason we don't do this is the same reason we don't reference 
the openlayers online version in the map preview. It is not that we 
don't want the overload servers it is that downloading external 
resources would make the client unacceptably slow. Imagine downloading 
the entire GML3 schema over a slow internet connection, it would be a 
nightmare.

I know that app-schema uses its own internal schema cache. I don't think 
people would be adverse to using this cache everywhere in GeoServer but 
this is an idea that has never been brought up and I don't think anyone 
but Ben and Rob know how it works.

The first step would be to start socializing that idea among developers. 
And saying that what we do now is wrong and clients should change to use 
"standard XML architectures" is not really the way to do that. A 
concrete proposal stating what the changes are, why we want to make 
them, and what the considerations are in terms of backwards 
compatibility, performance, etc... is the way to do it.

-Justin

Chris Holmes 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
> 

-- 
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

Reply via email to