[Community] CSW Review (Re: [SVN commit] (gispy) r1289 -OWSLib/trunk/owslib)

[Kralidis,Tom [Ontario]]

>Tom,
>
>I'd like to see classes and methods similar to the ones in the  
>existing modules (wms.py etc), providing the same interfaces. For  
>example
>
>   class CatalogService:
>       """instead of request"""
>
>       def getrecord(self):
>           """instead of GetCapabilities"""
>

Done.

>This is also more in line with Python PEP 8, capitalized class names,  
>lowercase method names. Any service should have a "capabilities"  
>property. See the wms.py, wfs.py, and wcs.py modules.
>
>Importing etree from owslib.etree tries lxml and then falls back on  
>elementtree or xml.etree, so do that instead of depending only on lxml.
>

It looks like lxml is tested last, no?

Here's where I'm falling down: if lxml proper is not used, the namespace support breaks, especially when constructing the XML message required for HTTP POST to a CSW.

Using elementtree or xml.etree, I haven't found a way (or examples) to construct valid XML requests.  Here's an example:

http://devgeo.cciw.ca/cat/GeneralQuery1.xml

Any suggestions?

>Pedantic me, I can not abide the name "fetch" for a method that makes  
>an HTTP POST request ;) GET is the HTTP method with fetch semantics.  
>Call it "_doRequest" or something. Probably shouldn't be part of the  
>public API.
>

Done.

>Lastly, let's get some tests in there soon.
>

In the same way as wms/wfs/sos, right?  Putting in docstrings right in the classes might bloat the code (responses can be big).

>I hope you don't mind the review. I just wanted to point out some  
>little things.

Not at all!  Thanks alot for your advice and irc help!  Much appreciated.

I haven't committed the updates yet, pending discussion on the lxml issue.

..Tom