Right now we make some assumptions about the prefixes passed in with typenames. This actually gets us into a bit of trouble with InsertRequest, since relying on the prefixes there just does not work so well. I implemented a hacky work around for this, but the real solution is to not rely on the prefixes of typenames being the same as our internal application. Ok, this begs a few examples: If I make a request like this: <wfs:GetFeature version="1.0.0" service="WFS" outputFormat="GML2" xmlns:wfs="http://www.opengis.net/wfs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:topp="http://www.openplans.org/topp" xsi:schemaLocation="http://www.opengis.net/wfs ../wfs/1.0.0/WFS-basic.xsd"> <wfs:Query typeName="topp:hong_kong"/> </wfs:GetFeature> Then we get the internal featureType that is stored as topp:hong_kong. But if we have another featureType called topp2:hong_kong, in the namespace http://www.openplans.org/topp2 Then a request like <wfs:GetFeature version="1.0.0" service="WFS" outputFormat="GML2" xmlns:wfs="http://www.opengis.net/wfs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:topp="http://www.openplans.org/topp2" xsi:schemaLocation="http://www.opengis.net/wfs ../wfs/1.0.0/WFS-basic.xsd"> <wfs:Query typeName="topp:hong_kong"/> </wfs:GetFeature> I think should actually return our topp2:hong_kong feature, since that's what the namespace is declared for, and the prefix should resolve to it (though this may be up for debate, since referring to a namespace prefix in an attribute, as the wfs spec does, is actually a pretty weird thing to do, and I don't know that you could even get the information with SAX). So this bug may actually beg some spec questions. Changing things completely over that way would then require that all our requests would need to have their namespaces declared, which would be annoying (though technically correct), especially for kvps. I like being able to just request things from a command line without trying to type out the full namespace declaration (as you are actually required to do by the ogc spec, kvps are a weakness there imho). So if we do this in geoserver I'd like to see it do both. Where this comes from is InsertRequest, which I have to make some nasty hacks on right now. A perfectly reasonable insert request is as follows: <wfs:Transaction service="WFS" version="1.0.0" releaseAction="SOME" xmlns="http://www.openplans.org/topp" xmlns:ogc="http://www.opengis.net/ogc" xmlns:wfs="http://www.opengis.net/wfs" > <wfs:Insert typeName="cdf:bc_roads"> <hong_kong> <gid>42</gid> <name>dude</name> </wfs:Insert> </wfs:Transaction> As you can see it does not refer to the topp: prefix, and I don't think we should force users to do that. Indeed, it would ultimately putting prefixes in to the gt2 feature model, which I think is the wrong route to go. Gt2 operates (or rather doesn't quite yet operate) on namespaces declared in featureTypes. So it would have a typeName and a uri. I think geoserver should do the same, basically a request should have getTypeName and getUri. GetTypeName right now returns a prefixed type name that we use internally (topp:hong_kong). We can still use the prefix internally, and indeed should, as it's a nice shortcut. But the entry should be with a uri. We could have request.getUri(Data data), which would then do the look-up on the prefix that the request stored for cases when requests are not able to obtain the actual uri. Anyways, I just wanted to get my thoughts out in how to get rid of this hack I had to put in TransactionResponse (which is the totally wrong place for it): if (element instanceof InsertRequest) { Feature feature = ((InsertRequest) element).getFeatures() .features().next(); if (feature != null) { String name = feature.getFeatureType().getTypeName(); String uri = feature.getFeatureType().getNamespace(); String typeName = catalog.getFeatureTypeInfo(name, uri) .getName(); element.setTypeName(typeName); } } Which was necessary, because there was no way to look up the prefix that we use internally before this point (and indeed I had to do a bunch of work just to get things working like this). (when testing this be sure that you're not testing with a fType in the default namespace, or it will work but the others won't).