The strategy pattern worked in regards to server behaviour. It did not work well with parsing mis-behaving XML documents. I was just always very permissive when it came to elements missing or empty, or in the wrong order. I think in order to separate a "pure" and a "permissive" XML parsing mechanism, I would need to have two definitions of the spec: one that is rigid, and the other that is as flexible as possible (what my current WMS one is). That seems like a lot of code/work duplication to me.
Richard Jody Garnett wrote: > Adrian Custer wrote: >> 4) WFS will be made permissive to incorrect requrests (but with some >> mumbling) >> > Um I had this discussion with Richard (for WMS) and also with David for > WFS ... > For WMS we have strategy objects that we delegate to that implement the > different policies > defined by each specification. This practice allows us to define > additional strategy object for > specific service implementations that are have issues.... > > I would like to maintain this idea, if I can ask the code to be "pure" > spec, all hacks/allowances > isolated in a manner similar to WMS (or a subclass if that is too hard). > > So Richard mostly raised this issue, I just ask that we provide a > technical solution to the problem > to prevent permissive code from making the code base a mess. > > So time to contact the module maintainer; and I would love to see the > design before giving this idea > a thumbs up. >> http://news.independent.co.uk/world/fisk/article1204432.ece >> * FrankW is reading about Lebanon... >> > That is crazy stuff Frank... >> <acuster> Would it be possible, in future releases, to somehow trim down >> the geoapi released with Geotools >> <acuster> to contain only the relevant modules? >> > That may be possible; but we can also pull an interesting trick I have > seen in other projects, > in our reference section only provide javadoc links to the packages that > matter to us... >> <acuster> I don't expect an answer, but am raising the possibility >> <acuster> Done >> > Darn - caught answering yet again :-) >> <rgould> so due to a recent bug issue in uDig, I discovered that the WFS >> plugin in geotools explodes if it encounters a Capabilities document >> that does not conform to the WFS specification >> <rgould> the problem is that the part that was missing from the document >> was not essential to use the service >> <rgould> now >> <rgould> a couple years ago, when I was implementing the WMS plugin, >> James gasped in dismay as he realized I was permitting servers that did >> not conform to the WMS specification to be accessed normally >> <rgould> i would like to do the same to WFS >> <rgould> (so we can access these broken servers) >> <FrankW> rgould: ++ on permissiveness. >> > Um, only if the code can still be maintained ;-) >> <rgould> I thought it might be a good idea to come up with a general >> concensus regarding what to do when something breaks specification >> > :-) > 1) isolate specification > 2) create dialects (derrived from the origional specification) that > allow for specific breaches of contract in a controlled manner > > This will be come more obvious when we have WFS1.0 and WFS 1.1 support. > > Cheers, > Jody > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
