[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