Just to clarify, going from memory I seem to remember that I have many coverages configured in various installations whose name contains: ^,[,],(,) etc. etc. Are we saying that these coverages won't work with GeoServer 2.0? I hope not, I would have an hard time convincing people to rework their configurations that contains thousands of layers!
Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Thu, Sep 10, 2009 at 7:23 AM, Gabriel Roldan <[email protected]> wrote: > 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.. > > Cheers, > Gabriel > > [1]<http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/datatypes.html#NCName> > [2]<http://www.w3.org/XML/xml-V10-4e-errata#E09> >> >> Cheers >> Andrea >> >> > > > -- > Gabriel Roldan > 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 > > ------------------------------------------------------------------------------ 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
