You make some good points
Basically, if you follow schema URLs,
* then you cant rely on the server being there
* you can point the client at the server to get the schema if the
mechanism exists
* it will be a pain if the canonical URLs are not used, as you will
have to fetch them every time you use a new server
Web browsers and non-validating clients do _not_ use schemas, so are
unaffected by any change.
The question still stands IMHO - is there any usage of the local
version by clients? You cant use an XML tool without an OASIS catalog
IMHO, and run-time validation is not common in other clients.
I think from here we should follow Andreas suggestion and have a
configuration flag to force use of canonical URLs, and start to
engineer in Gabriel's solution of a universal schema caching and
resolving capability, as opportunities permit.
I'd argue that theuse_canonical_schema_locations flag ought to be
default=true unless we can find evidence of real world clients using
the local references that will break.
Rob
On Wed, Dec 16, 2009 at 6:10 AM, Gabriel Roldan <groldan@anonymised.com> wrote:
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 <jdeolive@anonymised.com>
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.