Resolving hrefs in secore doesn't work across databases

[Dimitar Misev]

There is a user and an epsg (called 'gml') collections in secore, when a definition is in one of them, flattening the hrefs that point to definitions in the other doesn't work.

[Bang Pham Huu]

Hi Dimitar, as I've known, if one definition is both in (user and gml dictionary) so it only can query with definition inside user dictionary (as both pointed to 1 URI). Then if you have 2 definitions with different contents (you should create a definition with different id for it like EPSG:XXXX_USER in User directory or it will overlay default EPSG:XXXX in GML directory.).

So I think this ticket can be solved like this.

[Dimitar Misev]

Hi Bang, your comment is not related to this issue.

This is about 'flattening' of GML definitions, i.e. replacing href attributes to the XML content which they reference. If the definition is in the users dictionary, and it has hrefs pointing to the epsg dictionary, this cannot be resolved within the same flattening XQuery.

[Bang Pham Huu]

Thanks Dimitar, as now I've understood it correctly. However, I can not find any xlink:href from User dictionary to GML dictionary that can not be resolved. For example: it always converted URN to URI like

xlink:href="urn:ogc:def:cs:OGC::CartesianIndexed5D"
to
​http://www.opengis.net/def/cs/OGC/0/CartesianIndexed5D

So I would like to see one example for me to understand how it can be resolved as error.

Thanks.

[Bang Pham Huu]

I think it returns "<empty/>" in this case so I will try to see this problem soon.

<gml:CartesianCS xlink:href="urn:ogc:def:cs:EPSG::4400"/>

and this is not correct when the resolved URL does exist in

http://localhost:8080/def/cs/EPSG/0/4400
or
http://www.opengis.net/def/cs/EPSG/0/4400

[Bang Pham Huu]

ok, I've seen the XQuery and it looks like a maze, without any idea. So the real problem in here is when Dimitar wrote the query, you only query from "userdb" so if xlink:href to some definition from "gml" it of course will not work.

I just fix from your flatten functions like this then it will query from "gml" database also.

NOTE: this is confusing from description, so I'd like to fix it like this. Only reference from "userdb" to "gml" but not the reverse way. (Because if one modify definition from "gml" when save, it will add this new definition to "userdb" instead of updating).

The problem of this ticket is if a element has an attribute xlink:href which points to a definition in "gml" database. It will return '<empty/>'.

declare function local:getid($d as document-node(), $id as xs:string) as element() {
	let $retUserDB := $d//gml:identifier[fn:ends-with(text(), $id)]/..
	return if (empty($retUserDB)) then
            
                    let $retGML := collection('gml')//gml:identifier[fn:ends-with(text(), $id)]/..
                    return if (empty($retGML)) then
                             "<empty/>"
                           else
                             $retGML
 
                    
        else
                 $retUserDB[last()]                 

};

this is an example with xlink:href to "gml" database (epsg:changeID) will return <empty/>

<TimeCS xmlns="http://www.opengis.net/gml/3.2" xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="CS">
  <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/cs/OGC/0/tcs</identifier>
  <axis>
    <CoordinateSystemAxis id="time-axis" uom="%template-uom%">
      <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/axis/OGC/0/tcs</identifier>
      <axisAbbrev>%template-label%</axisAbbrev>
      <axisDirection codeSpace="http://www.ietf.org/rfc/rfc3986">%template-direction%</axisDirection>
      <epsg:changeID xlink:href="http://www.opengis.net/def/change-request/EPSG/0/2002.151"/>      
  </axis>
</TimeCS>

a patch will have in tomorrow.

[Dimitar Misev]

Great Bang, sounds good. Please make sure to include a test as well (JUnit would be sufficient).

[Bang Pham Huu]

thanks Dimitar. Close as patch was accepted.