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

[Gissur Þórhallsson]

Actually, after looking more closely, I think libxml2 is innocent.

I was inserting features with requests that contained only the geometry - it
seems I tried adding attributes to the insert around the same time as I was
upgrading my system. What mislead me is that INSERT worked for a small
subset of my layers (which have only one attribute) - so that had me barking
up the wrong tree.
The matter remains that I can not INSERT except through some insufferable
hanky-panky regarding column order on the database side - which for postgis
and 13 layers is no picnic. The funny thing is that all of this is
completely irrelevant when it comes to UPDATES.

Anyway - I must agree with you that an optional columns-order element would
be nice approach in fixing this.

Kind regards,
Gissur

On Sat, Feb 19, 2011 at 2:26 PM, Jean-François Gigand <
jean-francois at gigand.fr> wrote:

> Hi Gissur,
>
> Interesting!
> I use libxml2 2.7.8 on Debian.
>
> I have spent quite some time check the WFS et XML schema specs.
> I was surprised but this is the normal behaviour.
>
> If you noticed a difference between two versions of libxml2, I would
> guess that the new version is right and the older was too tolerant for
> this sequence elements order issue.
> Maybe a clue could be find in the libxml2 change log...
>
>
> JF
>
>
>
> 2011/2/19 Gissur Þórhallsson <gissur at loftmyndir.is>:
> > I suddenly started getting this message too.
> > I'm not entirely sure what happened - I've had tinyOWS running without a
> > hitch for a couple of months now and then all of a sudden I start to get
> > "xml is not valid"
> > And peeping into the logs gives me:
> > [Sat Feb 19 12:42:34 2011] [ERROR] Element
> > '{http://my.namespaceurl.com/}area': This element is not expected.
> Expected
> > is one of ( {http://my.namespaceurl.com/}date_created,
> > {http://my.namespaceurl.com/}date_modified,
> > {http://my.namespaceurl.com/}username,
> > {http://geoserver.loftmyndir.is/}origin ).
> >
> > Funnily enough this does not happen to all layers - simple layers (as in
> > with few attributes, in my case only numeric area and a text field for
> > comments) seem unaffected.
> > I can't for the life of my figure out why this popped up all of sudden -
> the
> > only thing I can relate this to is a system-wide upgrade I made on my
> box,
> > which is running ubuntu 8.0.4. LTS box- and if I correlate my
> tinyows.logs
> > with /var/log/apt/term.log I see that the "Expected is one of [...]" only
> > start to appear around the time I upgraded libxml2 to  libxml2
> > (2.6.31.dfsg-2ubuntu1.5) (I have no idea what version I was running
> before
> > that).
> > I'm going to see whether I can downgrade libxml2 and see if it changes
> > anything.
> > Or am I maybe barking up the completely wrong tree here?
> > Kind regards,
> > Gissur
> >
> >
> > On Mon, Jan 31, 2011 at 10:05 PM, Jean-François Gigand
> > <jean-francois at gigand.fr> wrote:
> >>
> >> 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
> >> _______________________________________________
> >> TinyOWS-users mailing list
> >> TinyOWS-users at lists.maptools.org
> >> http://lists.maptools.org/mailman/listinfo/tinyows-users
> >
> >
> >
> > --
> > Gissur Þórhallsson
> >
> > Loftmyndir ehf.
> > Laugavegur 13
> > IS 101 Reykjavík - Iceland
> > sími (tel): (+354) 540 2500
> > tölvupóstur (email): gissur at loftmyndir.is
> >
>



-- 
Gissur Þórhallsson

Loftmyndir ehf.
Laugavegur 13
IS 101 Reykjavík - Iceland
sími (tel): (+354) 540 2500
tölvupóstur (email): gissur at loftmyndir.is
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/tinyows-users/attachments/20110221/982af6c2/attachment.htm