[geotk] code for parsing WMS Capabilities docs

[Jon Blower]

Hi Johann,

I agree that a general XmlParseException would be a good idea (perhaps with a subclass indicating a failure of an XML doc to validate with its own schema?)

>> 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.

In similar code in the past, we have taken the XML stream and tried to validate it against the Capabilities schema.  If this works, we parse it as Capabilities.  If not, we validate against the XML exceptions schema.  If this works, we convert the XML doc to a Java exception and throw it.  If this doesn't work, we throw an exception indicating a failure to parse.  Can you use the same approach?  It's very important for cache control to be able to handle exception documents from the server, since the server indicates "Document not changed" by sending a CurrentUpdateSequence exception.  (Personally I think this is a little crazy, but it's in the spec...)

Cheers, Jon

-----Original Message-----
From: johann sorel [mailto:johann.sorel at geomatys.fr] 
Sent: 19 May 2010 21:47
To: Jon Blower
Cc: geotoolkit at lists.osgeo.org
Subject: Re: [geotk] code for parsing WMS Capabilities docs

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