[TinyOWS-users] Should the feature attributes order in XML matter ?

[Jean-François Gigand]

Hi,

For an 1.0.0 insert request, I get the exception "xml isn't valid"
with the following error:
[Mon Jan 31 21:11:05 2011] [ERROR] Element '{http://domain.net/}name':
This element is not expected. Expected is (
{http://domain.net/}deleted ).

"name" and "deleted" are (among others) valid feature attributes.
If I change the attribute elements order in my test request XML file,
and follow exactly the PostgreSQL column order for that table, it
works.

I am surprised. The WFS spec doesn't require a proper feature
attribute order in the list, does it?

Having checked the w3schools doc about XML Schema, the <xs:sequence>
element requires the element order to be respected.
I see that validation is done by libxml2, and of course is done well.

The problem, within the use cases of TinyOWS, is that PostgreSQL does
not provide any way to alter columns position.

You would say that the app should anyway fetch the feature schema by
issuing a DescribeFeatureType request, and deal with the features
according to it...

Actually, the OpenLayers serializer (exactly:
OpenLayers.Format.GML.Base.prototype.writers.feature._typeName)
creates the geometry first, then the attributes in object property
(for .. in).
If the geometry column in the PostgreSQL table is not the first (or
second after identifier), I could never insert any feature, and a
workaround with OpenLayers would be really messy.

This would be an issue of OpenLayers of course. But I think it
wouldn't break the logic to add to the TinyOWS configuration an
optional "columns-order" attribute on the <layer> elements.
That attribute would contain the comma-separated list of columns to
export to the WFS client in the order they should be listed in the
DescribeFeatureType sequence.

It would also allow to restrict the columns to export.

What do you think?

-- 
Jeff