[CITE-Forum] CSW DescribeRecord on latest beta

Lorenzo Bigagli lorenzo.bigagli at cnr.it
Wed Jun 26 08:35:50 EDT 2013


Hi all,

I would support Richard interpretation on this, i.e. type names should be explicitly qualified with their prefixes.

Please note that §10.6.4.2 seems ambiguous about where such namespaces should be declared:
p.136: For XML-encoded DescribeRecord requests, the namespace declarations are specified using the targetNamespace attribute of the TypeName element.
p.137: If the DescribeRecord request is XML encoded, then namespaces shall be declared according to the conventions of XML.

I would say that the 'shall' clause has a more normative character.

Best regards,
  Lorenzo

Il giorno 18/giu/2013, alle ore 20:05, Richard Martell <rmartell at galdosinc.com> ha scritto:

> Neil,
> 
> Lorenzo pointed out the relevant assertion in the catalogue spec:
> 
> "Every type name shall be fully qualified in order to indicate the target namespace for the
> type definition" (10.6.4.2).  
> 
> So the interpretation seems to be that a _prefixed_ name is required here even if schema validators 
> raise no objection.
> 
> 
> --
> Richard
> 
> 
> -----Original Message-----
> From: Neil Tippett [mailto:neil.tippett at envitia.com] 
> Sent: Tuesday, 18 June, 2013 01:42
> To: Richard Martell; Tom Kralidis; cite-forum at lists.opengeospatial.org
> Subject: RE: [CITE-Forum] CSW DescribeRecord on latest beta
> 
> Hi Folks,
> 
> Sorry to wade in on this topic, but I've run into the same issue as Tom. Whilst I agree that it appears to be a bug, I just wanted to point out that the TypeName is not unqualified - as a default XML namespace is provided it's qualified by the 'http://www.occamlab.com/ctl' namespace. Hence the request passes all the XML schema validation tools I've run it against. I would have thought that that fact would make the problem a little more clean cut?
> 
> Regards
> 
> Neil
> 
> -----Original Message-----
> From: cite-forum-bounces+neil.tippett=envitia.com at lists.opengeospatial.org [mailto:cite-forum-bounces+neil.tippett=envitia.com at lists.opengeospatial.org] On Behalf Of Richard Martell
> Sent: 04 June 2013 19:31
> To: Tom Kralidis; cite-forum at lists.opengeospatial.org
> Subject: Re: [CITE-Forum] CSW DescribeRecord on latest beta
> 
> Tom,
> 
> 
> An unqualified type name is the same as an unknown type name: empty response because nothing matches (or exception?).
> I recommend that a CR be submitted to revise 7.1 to make it schema-invalid, in which case an exception (400) is expected.
> 
> I've never seen exceptions appear within a normal response entity, but it strikes me as sensible in this case to indicate an unknown type name. 
> 
> What do you think, Lorenzo?
> 
> --
> Richard
> 
> 
> -----Original Message-----
> From: Tom Kralidis [mailto:tomkralidis at hotmail.com]
> Sent: Friday, 31 May, 2013 18:02
> To: Richard Martell; cite-forum at lists.opengeospatial.org
> Subject: RE: [CITE-Forum] CSW DescribeRecord on latest beta
> 
>> From: rmartell at galdosinc.com
>> To: tomkralidis at hotmail.com; cite-forum at lists.opengeospatial.org
>> Subject: RE: [CITE-Forum] CSW DescribeRecord on latest beta
>> Date: Fri, 31 May 2013 23:16:29 +0000
>> 
>> Tom,
>> 
>> 
>> Reading the assertions it looks like the intent of 3.1 is to supply a schema-valid request with an unknown type name.
>> But I believe 7.1 is intended to be a schema-invalid request; perhaps 
>> the unqualified csw:TypeName (Record) is supposed to render it 
>> invalid, but it doesn't really. I suggest a change is warranted here to make the intent more obvious (e.g. csw:typeName).
>> 
> 
> 
> Richard: thanks for the info.  So, for DescribeRecord, an unqualified typename passed should result in an ows:ExceptionReport?
> 
> Note that when I update my CSW with this logic the issues per this thread are solved (FYI I am still getting erroneous inherited errors).
>  
> Should I commit to this approach or does this need to be validated further?  Should I submit an issue to the issue tracker?
> 
>> Now about the significance of an unknown type in 3.1. An empty 
>> response (200) is expected, rather than an exception report. In 
>> essence, the net came up empty. One could argue that a response akin to a 404 (Not Found) is appropriate; the disadvantage is that a request for multiple types could be spoiled by one "bad apple".
>> It strikes me more as an impotent filter rather than a transgression, but views on this may vary.
>> Any other catalogue developers have an opinion?
>> 
> 
> As typename allows for> 1 typename to be specified, it might be useful to return the exception as part of the overall response.  So if someone asks for 3 typenames, 1 of them is bad, then return the 2 good typename csw:SchemaComponent's, and an inline ows:ExceptionReport for the bad typename.
> 
> Having said this, how does this relate to how GetRecords handles unqualified/invalid typenames?  Consistency would be valuable here across the spec.
> 
> 
> 
>> --
>> Richard
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: 
>> cite-forum-bounces+rmartell=galdosinc.com at lists.opengeospatial.org
>> [mailto:cite-forum-bounces+rmartell=galdosinc.com at lists.opengeospatial
>> .org] On Behalf Of Tom Kralidis
>> Sent: Friday, 31 May, 2013 13:29
>> To: cite-forum at lists.opengeospatial.org
>> Subject: [CITE-Forum] CSW DescribeRecord on latest beta
>> 
>> FYI when I run my CSW against http://cite.opengeospatial.org/te2 (username tomkralidis, test id=s0006), I receive the following error:
>> 
>> tc7.1
>> 
>> Test ctl:SchematronValidatingParser type Mandatory default result 
>> Passed (s0006/d1433e6483_1/d1433e6350_1/d1433e1324_1/d1433e1793_1)
>> 
>> Assertion: Validate an XML instance against a Schematron schema using the given phase.
>> 
>> Message d1433e177_1:
>>   Total number of errors detected: 1
>> 
>> Message d1433e183_1:
>>   Error 1: assertion failed:
>>  The document element must have [local name] = "ExceptionReport" and [namespace name] = "http://www.opengis.net/ows".
>>  The included document element has [local name] = DescribeRecordResponse and [namespace name] = http://www.opengis.net/cat/csw/2.0.2.
>> 
>> 
>> Result: Failed
>> 
>> Currently, my CSW implementation, when receiving a bad typename returns an empty csw:DescribeRecordResponse.
>> 
>> My initial thought after seeing tc7.1 is that invalid typenames should now, instead, return ows:ExceptionReport.  When testing again with this change, tc7.1 passes, but now I receive the following error:
>> 
>> tc3.1
>> 
>> Test ctl:SchematronValidatingParser type Mandatory default result 
>> Passed (s0006/d1433e6483_1/d1433e6350_1/d1433e1303_1/d1433e1516_1)
>> 
>> Assertion: Validate an XML instance against a Schematron schema using the given phase.
>> 
>> Message d1433e177_1:
>>   Total number of errors detected: 1
>> 
>> Message d1433e183_1:
>>   Error 1: assertion failed:
>>  The document element must have [local name] = "DescribeRecordResponse" and [namespace name] = "http://www.opengis.net/cat/csw/2.0.2".
>>  The included document element has [local name] = ExceptionReport and [namespace name] = http://www.opengis.net/ows.
>> 
>> 
>> Result: Failed
>> 
>> 
>> It looks like tc3.1 and tc7.1 have conflicting rules.  For a DescribeRecord request with an invalid typename, should a CSW server return an ows:ExceptionReport or an empty csw:DescribeRecordResponse ? 		 	   		  
>> _______________________________________________
>> CITE-Forum mailing list
>> CITE-Forum at lists.opengeospatial.org
>> https://lists.opengeospatial.org/mailman/listinfo/cite-forum 		 	   		  
> _______________________________________________
> CITE-Forum mailing list
> CITE-Forum at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum
> _______________________________________________
> CITE-Forum mailing list
> CITE-Forum at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/cite-forum



More information about the CITE-Forum mailing list