A TransactionFeatureHandler treats the xsi:schemaLocation attribute as an attribute of the feature, that is a feature will have an attribute of name schemaLocation (in namespace xsi). The following fragment shows the problem:
http://www.someserver.com/wfs/cwwfs.cgi?request=DESCRIBEFEATURETYPE - http://www.someserver.com/wfs/cwwfs.cgi?request=DESCRIBEFEATURETYPE
http://www.opengis.net/wfs - http://www.opengis.net/wfs
http:///schemas.opengis.net/wfs/1.0.0/WFS-transaction.xsd - http:///schemas.opengis.net/wfs/1.0.0/WFS-transaction.xsd">
This is a bit special, because these attributes are not usually found on a feature element. Most often xsi:schemaLocation is added on the root element. But according to xml schema specification (XML Schema Specification Part 1, section 4.3.2) it may occur on any element, not just the root element.
In TransactionFeatureHandler only xml attributes of certain namespaces should be added as attributes to the feature.
CodeHaus Comment From: cholmes - Time: Fri, 2 Jan 2004 18:26:25 -0600
<p>This should no longer be a problem. I decided that our feature reader should not mess with attributes at all. They only seem to cause trouble, and I've never heard of a valid use in gml of them. It is possible, but if people want to do it then geoserver and geotools need to rethink everything along the line. If we could read them in then the feature model would just squash them in to elements, and they would be returned that way. We would need an attribute flag in AttributeType to indicate that it should be returned as an attribute. So for now I think the best thing to do is to just ignore all attributes, and if there is a need to be able to read them in, then we can revisit, and also figure out how to print them out and handle them internally. </p>