Gabriel Roldan ha scritto: > Andrea Aime wrote: >> Simone Giannecchini ha scritto: >>> Hi list, >>> I was playing around today with geoserver trunk code and I noticed >>> that coverages with dot as part of the name do not work anymore due to >>> the new config/ui work. >>> This should be seen as a regression since it is quite frequent to have >>> raster data generated with dots as part of the name. >>> Should I opne upa Jira? >> >> I guess so. I know we have had issues with feature type names with dots >> as well, as they are common type names in SDE land, but they are not >> valid in WFS 1.1 (not sure about WFS 1.0). >> >> The current code in BasicResourceConfig adds a pattern validator >> like: [\\w_]\\w* (either a word char or a underscore and then only >> word chars). >> >> First off it would be nice to have a list of the valid patterns >> for the various services, and then we have to decide if being >> lax and allow invalid chars in the name for some services or not >> (e.g. say the dot is valid for wfs 1.0 but on wfs 1.1, what do >> we do?) > > aliasing works (around) just fine. > Irony is, dots _are_ valid characters for an element and attribute name > (except for the first character in the name) in XML. They're valid both > for xml Name and NCName[1]. > Not completely sure, but it looks like they're valid since November > 2008[2]. > The WFS 1.1 spec, section 7.3, also explicitly quotes the xml spec > NCName production rule and dots are included: > > #quote > [4] NCName ::= (Letter | '_') (NCNameChar)* > /* An XML Name, minus the ":" */ > [5] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | > Extender > [6] QName ::= (Prefix ':')? LocalPart > [7] Prefix ::= NCName > [8] LocalPart ::= NCName > #/quote > > and the attached xsd and xml instance do validate, so it's confirmed. > Yet I wonder why we (me included) were so convinced dots were not > allowed? No idea..
If I try to validate the following: <wfs:GetFeature service="WFS" version="1.1.0" xmlns:topp="http://www.openplans.org/topp"; xmlns:wfs="http://www.opengis.net/wfs"; xmlns:ogc="http://www.opengis.net/ogc"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd";> <wfs:Query typeName="topp:states.a.b.c"> <ogc:Filter> <ogc:FeatureId fid="states.3"/> </ogc:Filter> </wfs:Query> </wfs:GetFeature> Eclipse states: cvc-attribute.3: The value 'topp:states.a.b.c' of attribute 'typeName' on element 'wfs:Query' is not valid with respect to its type, 'TypeNameListType'. WFS_getFeature-1.1.xml /data-directories/release/demo line 8 XML Problem The same happens if I use any of the other chars in the production, like - or _. The reason is simple, TypeNameListType has an explicit definition of the valid pattern: <xsd:simpleType name="TypeNameListType"> <xsd:restriction base="wfs:Base_TypeNameListType"> <xsd:pattern value="((\w:)?\w(=\w)?){1,}"> which completely forgets about what a QName is. I've tried to validate a similar document but for wfs 1.0, that worked fine, as well as similar tests with wcs 1.0 and wcs 1.1 So I guess we can allow the qname allowed chars, but that will result in invalid WFS 1.1 setups, at least, it will not be possible to make a schema valid GetFeature XML request. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
