[Requests] ebRIM profile of CSW (RFPC 29) Response

Jason Cupp jcupp at esri.com
Sat Feb 18 05:13:41 EST 2006


[ continued ]

PART A
------

1. Evaluator: Jason Cupp jcupp at esri.com
2. Submission: OGC Request 29, OpenGIS Catalogue Services - ebRIM
profile of CSW (ebRIM)

PART B
------

1. Specification Section number: 9.1.8.1 - Invoking stored queries

2. Criticality: MAJOR

3. The 2nd paragraph states that 

".. a <wrs:StoredQuery> may appear in a GetRecords request instead of a <csw:Query> element."

 

but its schema in "pkg-basic.xsd" doesn't extend or declare it a substitution group for the csw:AbstractQueryType type or csw:AbstractQuery element. Won't the XML Schema validation fail in this case for the stored query?

 

 

 

1. Specification Section number: 9.1.8.1 - Invoking stored queries

2. Criticality: MAJOR

3. Specify the datatype for names and values of the slots that carry stored query parameters, and default parameters in the case of a rim:AdhocQuery instance. Recommend that slot names *must* be barewords as are the parameters (keys in the KVPs and attributes in the XML messages are NCNAMES) "maxRecords" and "startPosition", and that slot values are of the same type as defined for the parameters. The slotType attribute for pre-defined parameters would be *optional*, but *should not* conflict with the standard schema. Other parameters *may* include a slotType, and if present *may* be used to validate a stored query request message.

 

 

 

1. Specification Section number: 9.1.4 - csw:Query statements

2. Criticality: MINOR

3. Provide a BNF form for the variable references that *may* be present in a Filter instance and stored query:

 

<variable> ::= '$' <parameter-name>

<parameter-name> ::= <NCNAME>

 

I'm just throwing <NCNAME> in there. I don't know if there's a better definition contained in the ebRIM specification.

 

 

 

1. Specification Section number: 9.1.4 - csw:Query statements

2. Criticality: MAJOR

3. Recommend that instances of variables have a consistent form of:

 

<variable> ::= '$' <parameter-name>

<parameter-name> ::= <NCNAME>

 

in the data for csw:Query/@typeNames, stored queries and filter instances.

 

This would affect the examples 1, 2 and 3 of section 9.1.4:

(1) <csw:Query typeNames="rim:Service=$srv1,$srv2 rim:ExtrinsicObject">

(2) <csw:Query typeNames="rim:Service rim:Slot=$s1">

(3) <csw:Query typeNames='rim:ExtrinsicObject rim:Association=$a1'>

 

 

 

1. Specification Section number: 9.5 - GetRepositoryItem

2. Criticality: MAJOR

3. Drop the use of the "RepositoryItemFor" association in favor of the "ExternalLink" object

 

The GetRepositoryItem request *must* then be able to fetch both ExternalLink *and* Extrinsic objects using the "id" parameter.

 

 

 

1. Specification Section number: 9.5.3 - GetRepositoryItem response

2. Criticality: MAJOR

3. Strongly suggest that the GetRepositoryItem request *must not* perform a fetch of the resource as identified by the ExternalLink or respond with an HTTP redirect or 303 "See Other" on behalf of the client, as this negates the distinction of Extrinsic and ExternalLink objects. If either of these functions is used, then ExternalLink objects become invisible to clients which may desire to represent this kind of object and any other metadata it might contain. It's possible that secure clients may have the restriction of *not* being able follow re-direct links or be connected to the internet all together, which would effectively break the client's search for these kinds of objects.

 

 

 

1. Specification Section number: Table B.2

2. Criticality: MAJOR

3. Drop the "*:RepositoryItemFor" association type in favor of ExternalLink objects.

 

 

 

1. Specification Section number: 10.1.2 - Harvest Request

2. Criticality: MAJOR

3. If the object type of the csw:ResourceType element is an rim:ExternalLink object then the service *must not* attempt to fetch the resource and include it in the catalog as that would make it an Extrinsic object not an ExternalLink object.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/requests/attachments/20060218/7c2d4fce/attachment.htm


More information about the Requests mailing list