On Thu, May 20, 2010 at 12:32 PM, Jody Garnett <jody.garn...@gmail.com> wrote:
> We were just talking with Ben about how to make our parsers use schemas > provided as jar files - I don't quite understand his technique yet but I am > hopeful it can be adapted for wider use in the library. Great, and thanks for the swift reply. I was reading discussions on the mailinglist and got the impression that there was something on the todo list related to this. I'm now going to ask some elementary and/or stupid questions to understand how the parsing currently works, since as I looked into the testcase and ran it - it did not need any network connection. Additional schema definition in our xml: http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd ... Seemed to be the culprit. While looking through the code, the thing that baffles me is how does the parser in the testcase get the schemas - to transform Sax events into objects? Hints given to DocumentFactory was null - which indicates that parser or one of the handlers knows to look for defaults from somewhere, or that some geotools schema factory automaticly registers itself into SaxParserFactory. I've really tried to browse through the code in Netbeans and even grep around to find the usual suspects, but I am stumped at the moment :-D Any nudge, poke and wink to the right direction would be helpfull for us to understand how things work together. > The idea with this parser is that either it fetches the schema; or the > schema has been compiled into code. What version of WMS Capabilities are you > wanting to parse? Version 1.3.0. And everything works well, if we take out that additional namespace definition. Mind you that elemens from that namespace was not used in the document. Therefore I thought that the traditional way of giving schemas to the parser in JAXP style would have been sufficient. > Long term we would like to generate a new parser using the same technology > used by the gt-xsd-filter, gt-xsd-gml etc modules. Depending on your > interests perhaps you can help out? Haven't looked into there yet. What is the underlying technology used there? JAXB? Sax? Something else? I'm just a peon working in a limited time project, so can't commit any resources - but there is always the possibility that it would be nice excersice to do on the side. As a sidenote to the WMS module, could someone make following fix to the Extent class, unless it breaks something else. public class Extent extends org.geotools.data.wms.xml.Extent { public Extent(String name, String defaultValue, Boolean multipleValues, Boolean nearestValue, String value) { super(name,defaultValue,multipleValues,nearestValue,value); } public boolean isEmpty() { return value == null || value.length() == 0; } } This makes 1.3.0 Dimension's extents work again. Atleast in the simple scenarios. We have now forked relevant classes to our own project and use this fixed Extent class. -huima ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
