Opened 3 years ago

Closed 20 months ago

#819 closed defect (fixed)

Resolving hrefs in secore doesn't work across databases

Reported by: dmisev Owned by: bphamhuu
Priority: major Milestone: 9.0.x
Component: secore Version: development
Keywords: Cc: j.oosthoek, an.rossi
Complexity: Medium


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.

Change History (8)

comment:1 Changed 21 months ago by bphamhuu

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.

comment:2 Changed 21 months ago by dmisev

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.

comment:3 Changed 21 months ago by bphamhuu

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


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


comment:4 Changed 21 months ago by bphamhuu

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


comment:5 Changed 21 months ago by bphamhuu

  • Owner changed from dmisev to bphamhuu
  • Status changed from new to assigned

comment:6 Changed 21 months ago by bphamhuu

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


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

<TimeCS xmlns="" xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset" xmlns:gml="" xmlns:xlink="" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="CS">
  <identifier codeSpace=""></identifier>
    <CoordinateSystemAxis id="time-axis" uom="%template-uom%">
      <identifier codeSpace=""></identifier>
      <axisDirection codeSpace="">%template-direction%</axisDirection>
      <epsg:changeID xlink:href=""/>      

a patch will have in tomorrow.

Last edited 21 months ago by bphamhuu (previous) (diff)

comment:7 Changed 21 months ago by dmisev

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

comment:8 Changed 20 months ago by bphamhuu

  • Resolution set to fixed
  • Status changed from assigned to closed

thanks Dimitar. Close as patch was accepted.

Note: See TracTickets for help on using tickets.