There's the (reasonable) assumption that a client needing to download
the schemas at some time for parsing/validation would have a nicer time
by downloading them directly from the server than from the canonical
online resource. Both for speed and to avoid an unavailable online
server from preventing you working (schema.opengis.net happened to be
down a couple times actually).
This is course may not hold true for all cases. It would certainly do
for intranet users, for internet users nothing tells downloading from
geoserver would be faster, but certainly more reliable as you're already
working against the server.
That said, I see the value in using canonical URL's for schema locations.
But that doesn't even help for one of the most common use cases: user
downloads a wfs FeatureCollection and saves it as a gml file. Then wants
to use that file in another software. The server still needs to be
up/reachable to get to the featuretype schema, which _is_ server
dependent. At least one takes the time of downloading the schema too and
editing the gml file to make the schema location a relative reference...
Besides that, for WFS only most of the client software are desktop
applications? can't really know, but I doubt setting up an xml catalog
for a web browser is that easy, if it exists at all.
But still I see why using an OASIS Catalog where possible is valuable.
GeoTools most of the time avoids downloading schemas at all since it
have them in the jars. For the case of app-schema, this wasn't enough
because not the whole schema types/elements were bound to GeoTools so
not using an OASIS Catalog meant the GML schemas needed to be downloaded
everytime you use it, and the performance penalty was terrific. It also
had to permanently download GeoSciML schemas, etc.
All that said, what I'd like to see is a geotools module that produces a
jar file containing all the used schemas from schemas.opengis.net and
also provides an OASIS Catalog that hooks seamlessly in the geotools
parser/encoder, and can also be used by any application using geotools.
Then a switch in GeoServer to use canonical/custom schema locations
whose default preserves the current behaviour.
We could certainly do all of that, but it's not going to be trivial and
I'm not seeing the gain clearly. Sounds like the effort is greater than
the value to me, at least there's more compelling reasons. That is, I'm
pretty sure client software is NOT using xml catalogs. If they wanted to
use an OASIS Catalog though, they could just as easily add an entry for
the geoserver location so it can still use the cached copy without
changing a line of code in geoserver?
Cheers,
Gabriel
Justin Deoliveira wrote:
> 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.
> The wfs spec makes no mention of supporting an OASIS catalog. To be
> truthful I wrote the wfs 1.1 reference implementation and I don't even
> know what an oasis catalog is.
>
> I also don't think that telling people who are using geoserver on an
> internal network with no internet connection that "use an oasis catalog"
> is an acceptable upgrade path.
>
> 2c.
>
> -Justin
>> 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
>>>
>
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
