Thanks Ben - I understand that the XSD is not definitive, and that it is really just a bit of editing help, nothing more. I also agree that a GUI for editing configurations would be great, but that's a significant undertaking - it is not at all straightforward to think of what such an interface would even look like. In the meantime, the XSD certainly is quite helpful!
I certainly don't understand the ins and outs of the developer's process, but why couldn't the XSD just be made a part of the app-schema extension itself? Similar to the way that Geoserver always installs itself with a bunch of dummy data, couldn't the tutorial data just be included with the extension? Thanks, Ryan -----Original Message----- From: Ben Caradoc-Davies [mailto:[email protected]] Sent: Tuesday, August 03, 2010 10:58 PM To: Ryan Clark Cc: [email protected] Subject: Re: [Geoserver-users] Definitive version of AppSchemaDataAccess.xsd? Ryan, I have been avoiding this issue for years. :-) We use the version in the gt-app-schema test-data as the canonical version: http://svn.osgeo.org/geotools/trunk/modules/unsupported/app-schema/app-schem a/src/test/resources/test-data/AppSchemaDataAccess.xsd Technically, you should use the version matching the release tag of the build you have. The XSD is used *only* to aid manual editing of mapping files (they are read with a non-validating parser). See this warning next to a non-canonical copy in GeoServer. (I'll be including this in the next update of the app-schema tutorial): https://svn.codehaus.org/geoserver/trunk/src/extension/app-schema/app-schema -test/src/test/resources/test-data/AppSchemaDataAccess.README.txt The reason the mapping file XSD has not been published is that: (1) We do not have a suitable persistent place to store it (although I think we could put it somewhere on geotools.org). (2) We would have to version it for releases and update it every time trunk is updated, and this is quite a bit of trouble just for editing help. There are still some nasty issues (think of a developer making code changes to trunk pushing out XSD changes to the file while a deployer tries to edit a mapping file for a trunk snapshot). The underlying problem is that this XSD lacks a governance process. (2a) Feel free to use the canonical location in your schemaLocation; beware: the content and location will change without notice. (gt-app-schema is planned to be officially supported and will be moved). (3) We should have a GUI configuration editor so users do not have to edit mapping files by hand. At the moment AppSchemaDataAccess.xsd is subject to least-bad management, and copies of the file have less failure modes than the other possibilities. I am open to suggestions if anyone can recommend a better solution. Kind regards, Ben. On 04/08/10 06:32, Ryan Clark wrote: > I'm wondering if there is a definitive version of the AppSchemaDataAccess.xsd somewhere? I noticed that the schema that I downloaded along with the tutorial does not contain the<includedTypes> element. It is really useful to have this schema to work with, just wondering if there's one floating around that contains the includedTypes? > > Thanks, > Ryan > > > > -- Ben Caradoc-Davies <[email protected]> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
