[Geoserver-devel] schema.xml

GeoServer GeoServer Developer
1

I was following the recent discussion about schema.xml files loosely so I might have missed some things. I'm also using a relatively old build of geoserver so I am not up-to-date. I made some changes that will not work with the current version of geoserver but I'll move to geoserver as soon as 1.2 is available.

When I started with geoserver, you had to write a schema.xml file for every feature type you defined. I wrote the FeatureTypeTransformer and that's what I use since then, so there are no schema.xml files in my installation(s). It seems to me that generally the people on this list like schema.xml files. I personally prefer to live without them, if possible. FeatureType/AttributeType should contain enough information so that when the user/client creates a gml feature that validates against the xml schema generated by FeatureTypeTransformer (or whatever it is know) it does not generate any errors when inserted into the datastore. If a generic datastore can't provide enough information, because there are some other contstraints on the type of data (oracle datastore and geometries...), I would subclass the datastore and encode this information there. I'm using oracle db and in my case, there is a special db-table that specifies which table/column contains which type of geometries. There might be other constraints like the one just mentioned that are defined in external meta-tables (or in some other format). I don't want to be forced to write a schema.xml for this case because the same information I would have to write in the schema.xml file is already present in the database. Of course, this is just my case, there might be other people that don't have metatables and/or prefer schema.xml files.

If I had to install geoserver just once, I could live with the schema.xml files, but I'll most likely install more than one server. That's why I like the generated schemas so much. Do FeatureType/AttributeType provide enough information for FeatureTypeTransformer to create 'good' xml schemas. That is everything that validates against the schema validates also against the database schema? Is this not crucial for geotools users? They certainly don't want to mess around with schema.xml files. (?)

Another question? How is the current situation, do I have to write schema.xml files or does geoserver 'fall-back' on automatic schema generation based on FeatureType/AttributeType if there are no schema.xml files? Another solution for me would be to write a tool that reads all the information from the database to create the schema.xml files automatically.

I hope this information gives you some insight into possible problems users might face so that you can make geoserver/geotools as flexible and adaptible as possible.

Simon

2

Thanks for the email Simon, this is exactly the kind of input we have been lacking.

First of here is the current situtation in 1.2.0....

For 90% of our users...
1- you don't have to write a a schema.xml file
2- by default the ui says "generate" for the schema information
3- generate is different from the gt2 one, making use of the GMLUtils classes it now is a little bit smarter

For 9% of our users....
4- you can use the user interface to reorder or limit the attributes you share with the world
5- you can use the ui to be more specific about "type" then the DataStore FeatureType/AttributeType
    (You can restrict Geometry from oracle to be Point, without coding)
6- you can do all of this without writing any XML

For our 1% expert user that likes writeing a schema.xml file....
7- we appoligize, we are limiting what you can do: you cannot include files
8- the new restriction we are adding is you cannot do references within your file
    (we could relax this to account for a single level of indirection if you *need* it, we already support directly nested definitions)
9- you can use the UI to write an XMLFragment for each attribute you wish to do complicated restrictions

So in 1.2.0 we are helping two classes of users, at the expense of the expert users. The additional expense on the "expert" user is that they can no longer use intra file references.

When I started with geoserver, you had to write a schema.xml file for every feature type you defined. I wrote the FeatureTypeTransformer and that's what I use since then, so there are no schema.xml files in my installation(s). It seems to me that generally the people on this list like schema.xml files. I personally prefer to live without them, if possible.

Yep, me too. It has made thinking about the "expert" user difficult - since I have no experience with the capabilities that we are taking away.

FeatureType/AttributeType should contain enough information so that when the user/client creates a gml feature that validates against the xml schema generated by FeatureTypeTransformer (or whatever it is know) it does not generate any errors when inserted into the datastore.

Check.

If a generic datastore can't provide enough information, because there are some other contstraints on the type of data (oracle datastore and geometries...), I would subclass the datastore and encode this information there.

Nope, you are a nice hard core Java programmer. While I would like oracle datastore to get smarter, we need to allow subtyping at the config level. (Not just for geometries, there is that expert user out there still).

I'm using oracle db and in my case, there is a special db-table that specifies which table/column contains which type of geometries. There might be other constraints like the one just mentioned that are defined in external meta-tables (or in some other format). I don't want to be forced to write a schema.xml for this case because the same information I would have to write in the schema.xml file is already present in the database.

I wanted to set this kind of situtation up, where the DataStore can make use of database external meta-table to supply additional constraints. I have done a bit of work with respect to this using the gt2 Catalog/FeatureTypeMetaData/AttributeTypeMetaData.

Unfortuantly without database meta-tables to drive this use case, this code will languish.

If I had to install geoserver just once, I could live with the schema.xml files, but I'll most likely install more than one server. That's why I like the generated schemas so much. Do FeatureType/AttributeType provide enough information for FeatureTypeTransformer to create 'good' xml schemas. That is everything that validates against the schema validates also against the database schema? Is this not crucial for geotools users? They certainly don't want to mess around with schema.xml files. (?)

Yes FeatureType/AttributeType provide information that is "good enough", but XMLSchema allows more then we can ever get out of FeatureType/AttributeType or even metadata tables. Part of being a "reference implementation" is that we should not limit people form doing more.

Of course we are, which meens we will have to revisit this issue, the first time an expert user shows up.

To actually do this for real:
- schema.xml to be a real XML file allowing includes
- we would need an XMLSchema parser ensure match between schema.xml is a propert subset of FeatureType/AttributeType
- combine schema.xml file with describe type document, this is tricky on the includes front