[OWSLib-devel] nextRecord missing

Tom Kralidis tomkralidis at gmail.com
Tue Oct 22 05:21:56 PDT 2013



On Tue, 22 Oct 2013, David Read wrote:

> Date: Tue, 22 Oct 2013 13:10:52 +0100
> From: David Read <david.read at hackneyworkshop.com>
> To: Tom Kralidis <tomkralidis at gmail.com>
> Cc: owslib-devel at lists.osgeo.org
> Subject: Re: [OWSLib-devel] nextRecord missing
> 
> Thanks Tom. I've opened the issue and will submit a pull request,
> including the test.
>
> Yes, "nextrecord: None" would mean the element did not exist, unless
> you think the key should not be returned at all?
>

This would result in a KeyError, which IMHO may prove brittle given
the usage of owslib.csw out there.

> Is there some documentation or something where we can warn OWSLib
> clients to not rely on the nextRecord value existing?
>

Maybe along with setting nextrecord to None
we can also do a warnings.warn to say this? At least it will catch in
downstream Python logs, then?

> David
>
> On 22 October 2013 12:50, Tom Kralidis <tomkralidis at gmail.com> wrote:
>>
>>
>> On Tue, 22 Oct 2013, David Read wrote:
>>
>>> Date: Tue, 22 Oct 2013 12:33:37 +0100
>>> From: David Read <david.read at hackneyworkshop.com>
>>> To: owslib-devel at lists.osgeo.org
>>> Subject: [OWSLib-devel] nextRecord missing
>>>
>>>
>>> Have any of you encountered a CSW Server that doesn't give a
>>> nextRecord value when doing a GetRecords request? I'm using OWSLib to
>>> talk to it and it gives an exception and I have a patch I can push
>>> that'll avoid the exception. But is that what we want it to do?
>>>
>>> The server is running "Conterra sdi.suite". Apparently Conterra's view
>>> is that it is best practice for the client to keep track of where it
>>> is up to, and not to rely on the server, and so they adhere to the XSD
>>> schema rather than the guidance on this particular issue.
>>>
>>> The schema http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd says
>>> it is OPTIONAL:
>>>
>>> <xsd:attribute name="nextRecord" type="xsd:nonNegativeInteger"
>>> use="optional"/>
>>>
>>> yet the spec it claims to reflect says it is REQUIRED:
>>>
>>> http://portal.opengeospatial.org/files/?artifact_id=21460
>>>
>>> <xsd:attribute name="nextRecord"
>>>                     type="xsd:nonNegativeInteger"
>>>                              use="required"/>
>>>
>>> Is the XSD (and therefore Conterra) simply wrong? Or is this justifiable?
>>>
>>
>> Unfortunately, D.1.1 of the spec says:
>>
>> "In the event of a discrepancy between the bundled and online versions of
>> the
>> XML Schema files, the online files shall be considered authoritative."
>>
>> Though it would be really nice (and really easy) for the CSW server impl to
>> support nextRecord.
>>
>> This will also trip up existing OWSLib clients who may be doing something
>> with
>> nextRecord already assuming it's an int?
>>
>> David: sure, submit a PR against master? It would be really really great
>> also
>> if you could provide a small test case in our doctests.
>>
>> example:
>> https://github.com/geopython/OWSLib/blob/master/tests/doctests/csw_nlr.txt
>>
>>
>>> BTW here's my patched version of OWSLib running:
>>>
>>>   >>> from owslib.csw import CatalogueServiceWeb as cs
>>>   >>> c=cs('https://gateway.ceh.ac.uk/soapServices/CSWStartup')
>>>   >>> c.version
>>>    '2.0.2'
>>>   >>> c.getrecords2()
>>>   >>> c.results
>>>    {'matches': 291, 'nextrecord': None, 'returned': 10}
>>>
>>
>> So nextrecord: None would mean that the element did not exist, correct?
>>
>>> David
>


More information about the OWSLib-devel mailing list