> 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.
Right it does not have that schema "compiled" into java code so it was forced
to go and ask.
Here is the thing - geotools has:
1- sax parser (origional and still going)
2- dom parser (second place and still useful)
3- the wms and wfs 1.0 parser used to prove the idea of making a bunch of
little small sax parser "bindings" and using the schema to call them in the
right order
4- the gtxml parser used for wfs1.1 and a bunch of others based on the above
proof of concept and actually documented etc...
So guess what code should be updated :-(
Here is an article on the design -
http://udig.refractions.net/confluence/display/OWS3/GTXML+Article
And the user guide section covering the above: 13 XML
And you are much better advised to run through the documentation for the gtxml
parser in order to understand how it works:
- XML Developers Guide
When you have read that and have questions we can answer the question on why it
does not need to look up the xml schema together.
> 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
Actually the developer made it difficult on purpose in order to discourage
questions. Things that used to be static final constants were lumped into an
array of things and referenced by number. Every time I have to debug it I add
the constants back in.
> Any nudge, poke and wink to the right direction would be helpfull for us to
> understand how things work together.
There are a bunch of links above; other then that please keep the questions
coming :-) I am likely to be on the email list with questions
myself as I look at WPS.
>
>> 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.
No you need to "compile" them into Java; or apparently Ben found a way to ask
the new parser (ie 4 above) to grab them from a jar.
>
>> 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?
SAX backing on to a series of bindings; one for each XSD entry; the XSD is
treated as a "program" determing what "binding" to handle the parsing/encoding
at any point in time.
> 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.
Strangely enough so am I which is why wms is not migrated to the new parser.
> As a sidenote to the WMS module, could someone make following fix to
> the Extent class, unless it breaks something else.
Now that the release is out of the way I should be able to look at it.
> 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.
If possible we try and arrange for projects such as yours to go through the
steps to have commit access - just so they are not held up waiting on volunteer
time such as mine :-( You may also consider a support contract, there are a
number of organisations listed on the website, one of which is mine. Although
the project would prefer more volunteers.
Jody------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
