[geotk] code for parsing WMS Capabilities docs

johann sorel johann.sorel at geomatys.fr
Wed May 19 16:46:39 EDT 2010


Hi jonathan,

Le 19/05/2010 16:23, Jon Blower a écrit :
> Hi Johann (and Cedric),
>
> Thanks for your responses.  I think it is necessary to be able to pass
> UPDATESEQUENCE - clients should not cache Capabilities docs forever, as
> the underlying data may change.  In our case, the WMSs represent ocean
> forecast models, and the data changes many times a day.
>
> I think UPDATESEQUENCE will have to be a string, since the spec says
> that it can be a timestamp or an integer counter.
>    
I understand your concern now, I actually wasn't aware this parameter
was avaible on capabilities queries. That change should be applied on all
our clients. I don't know when we will fix this task, so if you are in a 
hurry
you can write a patch for WMS and we'll apply it on all others.

> For exceptions I think we need:
> 1. IOException for server connection problems.  (InterruptedException is
> not suitable as this is related to threads.)
>    
Agree on this one, (I said InterruptedException by having a quick look to
the underlying code).
> 2. Some exception that shows that the XML response can't be parsed.
> java.text.ParseException may be OK, but requires an integer offset
> showing which character caused the problem, which may be hard to find.
> Following Bloch's guidelines of "throw Exceptions appropriate to the
> abstraction" I suggest creating your own checked exception type
> "CapabilitiesParseException" or similar that wraps whatever the
> underlying exception is.
>    
A capabilitiesParseException would be a bit to specific I believe.
I had a hard time (several months we can say)
to achieve a first global cleanup of every module and get ride of 
duplicate code and
classes, including Exceptions. Actually there are not much different 
exceptions remaining.
I do not wish to add a new exception for a unique query type.
A more general XMLParseException would be better and reusable in much 
more places.


> 3. An exception that is thrown when the server returns a WMS Exception
> (e.g. CurrentUpdateSequence). In this case the server will return an XML
> document containing the exception, which Java code should translate into
> a checked exception.
>    
I'm not sure we can do a distinction between 2 and 3 since the stream is 
directly send
to the parser.


> Thanks for all the rest of the information!  If I grab the next SNAPSHOT
> release, will I get the code for reading a layer's title and abstract?
> Or do I have to wait longer?
>
> Thanks, Jon
>    


johann sorel



More information about the Geotoolkit mailing list