There is one other option; for tables that cannot be published as is ... leave them unpublished. They will still be useful when setting up an "application schema" which provides the facilities to "remap" names.
What do you mean by an escaped alias? Something simple such as replacing "invalid" name characters with an "_" in the geoserver FeatureSource wrapper? Thus "foo.bar" would be published as "foo_bar". Jody On 05/09/2009, at 2:17 AM, Gabriel Roldan wrote: > Becoming strict by default will mean no ArcSDE instance can run by > default due to the feature type names being non valid xml CName as > they > have dot characters. > > That said, I like the idea of being strict by default and having a > global switch (don't we already have it on a per-service basis, and it > would mean just shipping with inversed default?). > > So, on the feature type name thing, I repeat myself saying I think > GeoTools FeatureType names shouldn't be forced to obey GML naming > rules > (after all so much effort were put on the FeatureModel not being > tied to > GML but to the General Feature Model), but GeoServer ones (at least > WFS > ones) shall be. So, not to get that off topic, do you think we can > become strict by default _and_ patch geoserver to force type names > being > gml valid? > > It wouldn't be the first time someone complains his database table > can't be published because of having a space in the name, etc? > > Option 1, which I don't quite like, would be wrapping so type names > are > escaped somehow. > > Option 2, depend on the resource/publish split and would be > assigning an > escaped layer name, but may be we could alleviate by assigning an > escaped alias in the mean time? > > Gabriel > > David Winslow wrote: >> What about a global configuration option that controls whether >> strictness is enforced by default? Maybe we could include a >> validation >> report in exception messages? There may be something between black >> and >> white here. >> >> -- >> David Winslow >> OpenGeo - http://opengeo.org/ >> >> On Fri, 2009-09-04 at 07:32 -0600, Justin Deoliveira wrote: >>> As always this is a tough call. When thinking just about the user >>> who is >>> hacking up a one off request, I agree strictness is probably the >>> way to >>> go. But what about people who have sizable client applications built >>> that rely on this tolerance by default? Even a simple change such as >>> adding a parameter to the request (?strict=false) can make the >>> upgrade >>> to 2.0 a deal breaker if we are talking about many clients deployed. >>> >>> Anyways, i am not against this, i just think that we will run into a >>> "grass is greener" situation in which once we enable the flag, >>> instead >>> of running into many confused users, we will run into many irate >>> ones >>> whose applications stop working. >>> >>> Interested in hearing other peoples opinions. This should probably >>> be >>> discussed on the users list. I am in particular interested to hear >>> from >>> those who have already gone through an upgrade and dealt with xml >>> parsing behavior changes. >>> >>> 2c. >>> >>> >>> Andrea Aime wrote: >>>> Hi, >>>> the 2.0 in the release is there to signify a change. It's the UI, >>>> it's >>>> the config subsystem. >>>> >>>> I was wondering if it could be a good occasion to start being >>>> strict >>>> about xml request schema compliance? >>>> We could have a flag and make strict the default, but allow >>>> people to >>>> turn that off and fall back on the non strict behavior. >>>> >>>> I'm asking this because I keep on hearing people confused because >>>> the parser just skips over the elements it does not understand >>>> and people are left wondering what's wrong. I know that one >>>> can append ?strict=true to the url to have schema validation >>>> done, the problem is that those users tripping into the lack >>>> of error messages don't ;-) >>>> >>>> Cheers >>>> Andrea >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > -- > 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 > Geoserver-devel@lists.sourceforge.net > 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
