FeatureType XML Definition

Description

Chris this one wants your approval/understanding before anyone should work on it.

Section 2.3.3 VWFS Implementaiton Report

GeoServer currently uses XML Fragments for the schema.xml and info.xml
used to describe FeatureTypes. These fragments are stored in a directory based
on the FeatureType name.
Recommendations for FeatureType Definition:

  • Use complete XML Documents for schema.xml and info.xml
    * Remove orphaned <attributes> tag from info.xml.
    * Store FeatureType configuration by DataStore Id
    These changes would allow the use of a validating XML parser and prevent
    FeatureType name conflicts across data sources.

Environment

None

Activity

Show:
codehaus
April 10, 2015, 4:32 PM

CodeHaus Comment From: cholmes - Time: Thu, 5 Feb 2004 17:59:37 -0600
---------------------
<p>Ok, I'm definitely for removing the attributes tag stuff, just explain where it went, preferably in the example files as an xml comment (just saying that it's specified in the schema.xml file, why the change, how to specify mandatory, ect.). Complete xml documents for info.xml is trivial, I'm all for that. As for the schema.xml files, there's a few things I want to see if we do this change. The reason they were fragments before is because it's a bitch for users to figure out all the weird imports and namespaces that must be present. So we had geoserver do it for them, since it already had knowledge of them. So I don't want to make it more complicated for users. This is somewhat alleviated by the fact that now most users will just use the generated schema stuff. What I want to be sure of is that for a user who is just using the file stuff (completely ignoring the web configuration stuff) will have an easy time configuring his schema.xml file. This can be accomplished (and you may already do this) by having the schema.xml file created automatically for him if none is present. So the use case would be this. User specifies an info.xml file. Starts up GeoServer once (no web app at all), perhaps does a DescribeFeatureType (though would be nice if this step wasn't necessary), and after that happens there is a full schema.xml file in the same directory as the info.xml file. He can then just modify this with a text editor, and on the next start up geoserver will use that instead of generating it. You guys may already do this, I just want to be sure that if anything it is easier for the user who is just using files (since that's how I usually operate, if you've been working with a product for awhile and know how the config files work it is easier to just stick with that, I don't want to force the webapp on anyone, since it is an added complexity). And of course this use case should be well documented. (I'm sorry that I don't know how you guys persist things now, but I actually haven't got that part of 1.2 to work yet, last time I did the save xml and to geoserver it didn't seem to really do anything, I'll try again soon though).</p>

<p>As for the last one, I'm not sure I quite understand. Do you just mean name the folder by the datastore id by default? Or do you mean something else?</p>

codehaus
April 10, 2015, 4:32 PM

CodeHaus Comment From: jgarnett - Time: Thu, 5 Feb 2004 18:34:16 -0600
---------------------
<p>I would prefer not to have a file at all if the user want the XMLSChema automagically generated.</p>

<p>Could we ask the user to open up the web config and hit a "generate" button on the FeatureType page?</p>

<p>I don't think we have our heart set on making these real XMLSchema documents - it just would be smart on several levels.</p>

<p>For the last point the idea is to restructure how the files are stored in the data directory: I though that each folder was named the same as the type inside of it based on namespace--typeName.</p>

<p>I wanted to switch this to dataStoreId--typeName or dataStoreId/typeName.</p>

<p>It is hard to know what is going on with the featureTypes directory just by looking. I want a way in which I can autogenerate folders for typeNames and not have conflicts.</p>

codehaus
April 10, 2015, 4:32 PM

CodeHaus Comment From: cholmes - Time: Thu, 5 Feb 2004 18:50:04 -0600
---------------------
<p>EXTERNAL MESSAGE:

SUBJECT: Re: <span class="error">&#91;jira&#93;</span> Updated: (<a href="https://jira.codehaus.org/browse/GEOS-90" title="FeatureType XML Definition" class="issue-link" data-issue-key="GEOS-90"><del>GEOS-90</del></a>) FeatureType XML Definition

#&gt; Could we ask the user to open up the web config and hit a "generate"

#&gt; button on the FeatureType page?

I'll think about it. I spose another option would be to tell users to cut

and paste from a describe response if they want a shortcut to doing it

themselves. I don't like forcing users to open the web config though.</p>

<p>I think the datastore id should be fine. It's actually all arbitrary now,

the namespace stuff is just recommended, and necessary where there are

namespace conflicts. So yeah autogenerate on datastore/typename, you

should be fine.</p>

<p>&#8211;</p>

codehaus
April 10, 2015, 4:32 PM

CodeHaus Comment From: cholmes - Time: Tue, 17 Feb 2004 15:25:47 -0600
---------------------
<p>Not really depends upon, but 49 contains the irc where we resolved what to do about this.</p>

codehaus
April 10, 2015, 4:32 PM

CodeHaus Comment From: cholmes - Time: Tue, 17 Feb 2004 15:26:16 -0600
---------------------
<p>See irc in geos-49, we agreed upon what to do here.</p>

Fixed

Assignee

Unassigned

Reporter

codehaus

Triage

None

Fix versions

Affects versions

Priority

Low