Test Case ad-as.b.1 Fails Incorrectly

[mpleic]

Hi,

I found an issue with test case ad-as.b.1 that fails even though the data is correct.

Problem

Test case ad-as.b.1: An address shall have an admin unit address component spatial object whose level is 1 (Country) fails when validating GML data that correctly contains AdminUnitName components with level 1stOrder (Country).

What's happening

In the test case (line 358 in ets-ad-as-bsxets.xml), the XPath expression uses:

if ($element/ad3:level/text()='1stOrder' or $element/ad:level/@xlink:href='http://inspire.ec.europa.eu/codelist/AdministrativeHierarchyLevel/1stOrder') then

The main problems are:

1. Incorrect namespace prefix: It uses ad3:level but the GML uses ad:level (the ad3: prefix doesn't match the actual namespace prefix in the GML data)
2. Incorrect value check: It looks for text content in the level element (/text()='1stOrder'), but level is of type gml:ReferenceType which cannot have textual content according to the schema. The value should be checked via the xlink:href attribute only, which contains the unique identifier URI (http://inspire.ec.europa.eu/codelist/AdministrativeHierarchyLevel/1stOrder)

Example data

In the attached ZIP file, you'll find XML files:

• ad_Address.xml - contains Address objects with component references
• ad_AdminUnitName.xml - contains AdminUnitName objects with level elements

Example Address object:

<ad:Address gml:id="Address.2178420683">
    ...
    <ad:component xlink:href="#AdminUnitName.2183871399"/>
    ...
</ad:Address>

Example AdminUnitName object with level 1stOrder:

<ad:AdminUnitName gml:id="AdminUnitName.2183871399">
    ...
    <ad:level xlink:href="http://inspire.ec.europa.eu/codelist/AdministrativeHierarchyLevel/1stOrder" xlink:title="1stOrder"/>
    ...
</ad:AdminUnitName>

Where:

• ad: = http://inspire.ec.europa.eu/schemas/ad/4.0 (Addresses namespace)
• xlink: = http://www.w3.org/1999/xlink (XLink namespace)

Recommended solution

The XPath expression should:

1. Use the correct namespace prefix (ad: instead of ad3:)
2. Check the xlink:href attribute as the primary way to identify the level value (since level is ReferenceType and cannot have textual content)

if ($element/ad:level/@xlink:href='http://inspire.ec.europa.eu/codelist/AdministrativeHierarchyLevel/1stOrder') then

The xlink:href URI is the unique identifier for the level value and should be the primary check, not text content or xlink:title.

Additional information

• We're also attaching the validation test report for reference
• All other test cases in the same test suite pass correctly

Attachments

INSPIRE_Internal_WFS_AD_ad.zip
INSPIRE_Internal_WFS_AD_ad_GML.html

Thanks for looking into this!

[fabiovinci]

Dear @mpleic,

it is unclear which resource you used for validation: the GML containing only the Address feature type or a WFS.

In any case, looking at the sample datasets you provided, I noticed that the ad_Address.xml file contains "internal" references to the different components:

  <ad:component xlink:href="#ThoroughfareName.2156427654"/>
  <ad:component xlink:href="#PostalDescriptor.2184952018"/>
  <ad:component xlink:href="#AdminUnitName.2178203977"/>
  <ad:component xlink:href="#AdminUnitName.2183871399"/>

so the validator is not able to retrieve the related feature types and check the constraints.

Merging all the files in a unique XML (ad_Address_complete.zip), the validator can retrieve all the address components and verify the constraints (see the related test report).

I hope this provides a clearer understanding.

[mpleic]

Dear @fabiovinci,

Thank you for your quick response regarding the feature references issue in our INSPIRE Addresses GML validation.

Our Use Case and Workflow

We use WFS network services within our internal network to produce INSPIRE GML files that are then served via ATOM network services. Our workflow is:

1. WFS services generate GML data on-demand from our spatial database
2. GML files are packaged into ZIP archives
3. ZIP archives are distributed via ATOM feeds

We package each feature type in a separate GML file within the ZIP archive (e.g., Address.gml, AdminUnitName.gml, ThoroughfareName.gml, PostalDescriptor.gml) for several important reasons:

1. File Size and Complexity

• Our Address dataset contains over 1.6 million addresses (uncompressed ~2.5 GB for Address feature type alone)
• More complex datasets like Transport Networks have even larger feature types with more complex relationships
• Combining all feature types into a single GML file would create extremely large files that are difficult to process, maintain, and validate
• Currently, we validate smaller subsets of datasets (e.g., 50-100 objects and their relationships) to ensure data quality; validating entire large datasets as single files would be significantly more complex

2. Modularity and Reusability

• Different feature types may be updated at different frequencies
• Separate files allow for incremental updates without regenerating entire datasets
• Other systems can consume specific feature types independently if needed

3. WFS App-Schema Implementation Constraints

• Our GeoServer implementation uses app-schema for complex features (INSPIRE application schemas)
• Join queries for multiple feature types are significantly more complex to implement and require explicit filters
• Since we export complete datasets, it is logical to avoid complicating the situation with join queries when relationships can be maintained through references
• We simply export all feature types as separate feature collections (one feature type per WFS GetFeature request), which is the standard and more straightforward approach

4. Data Organization Best Practices

• This structure follows the principle of separation of concerns in data organization for the data provider

The Problem: Cross-File References

As you correctly identified, our GML files currently use local references with the # symbol:

<ad:component xlink:href="#ThoroughfareName.2156427654"/>
<ad:component xlink:href="#AdminUnitName.2178203977"/>

We use local references (#id) because:

• The validator currently only supports local references (with # symbol) or HTTP/HTTPS URLs
• All other reference formats are treated as HTTP requests/URLs that must be dereferenced on a server, HTTP/HTTPS URLs are not appropriate for pre-packaged GML files in ZIP archives distributed via ATOM feeds, as this
  would defeat the purpose of packaging data for offline distribution
• Packaging all feature types into a single GML file is not an option for us due to complexity constraints (as explained above)
• We therefore use local references as a pragmatic solution, knowing that the referenced IDs exist in files that come together with the address data in the same ZIP archive

When features are split across multiple files in a ZIP archive, relative path references would be the appropriate solution:

<ad:component xlink:href="./ThoroughfareName.gml#ThoroughfareName.2156427654"/>
<ad:component xlink:href="./AdminUnitName.gml#AdminUnitName.2178203977"/>

Support for Relative Paths in specifications

INSPIRE Data Specification Support:
According to INSPIRE D2.7 "Guidelines for the encoding of spatial data" (INSPIRE Data Specifications), Annex D (Encoding of file-based data) explicitly states that GML "by-reference" mechanism is used via xlink:href, and that the "full richness of the XLink specification" can be utilized. The specification notes that href can be used "for referencing one or more files ... (e.g. a file name or URI)".

According to the GML specification and XLink standard, xlink:href attributes can contain:

• Fragment identifiers (#id) - for references within the same document
• Relative URIs (./file.gml#id or file.gml#id) - for references to other files in the same archive/package
• Absolute URIs (http://example.com/file.gml#id) - for references to external resources

GML Specification (OGC GML 3.2.1, OGC 07-036):

• Section 7.2.3 "GML properties" (specifically 7.2.3.1 "Introduction") defines property elements that may use two modes: "inline" (value represented directly) and "by reference" (value identified by xlink:href attribute)
• The specification states: "by reference: the value of the property is available elsewhere, and is identified by the value of an xlink:href attribute on the property element"
• The specification allows both fragment identifiers and relative/absolute URIs in xlink:href attributes
• GML follows XLink 1.1 for URI resolution semantics

XLink 1.1 Specification (W3C Recommendation, 6 May 2010):

• Section 5.2 "Simple Links" defines simple links that associate exactly two resources (one local and one remote)
• The specification supports relative references in xlink:href attributes
• Relative references must be resolved to absolute URIs before use, according to RFC 3986

This indicates that INSPIRE allows the use of relative file references in xlink:href attributes for cross-file references within packaged datasets, as do the GML and XLink specifications.

Current Validator Limitation

When we tested relative path references (e.g., ./AdminUnitName.gml#AdminUnitName.2178203977), the validator reported:

XML document 'Address.gml', Address 'Address.2178420683': The property 'component' has a value './ThoroughfareName.gml#ThoroughfareName.2156427654,...' that cannot be retrieved using HTTP.

This indicates that the validator currently only supports:

1. Local references (#id) - within the same XML document
2. HTTP/HTTPS URLs - for external resources

But not relative file paths within ZIP archives.

Our Request

We would like to know if support for relative path references within ZIP archives is planned for the "Feature references" test cases (e.g., ad-ia for Addresses, and similar test cases for other INSPIRE themes).

As we have shown, INSPIRE, GML, and XLink specifications all allow relative file references. If the validator will support this, we are prepared to modify our implementation to use proper relative path references (e.g., ./AdminUnitName.gml#AdminUnitName.2178203977) instead of local references.

In the meantime, we will adapt our validation process for smaller subsets of datasets by merging them into a single GML file and validating them as such, which allows the validator to resolve local references correctly.

This would:

1. Enable validation of properly structured multi-file GML archives
2. Align with INSPIRE/GML/XLink specifications that allow relative URIs
3. Support real-world use cases where large datasets are split across multiple files

Proposed Implementation

When the validator encounters an xlink:href with a relative path (e.g., ./AdminUnitName.gml#AdminUnitName.2178203977):

1. Resolve the relative path within the same ZIP archive context
2. Load the referenced GML file from the archive
3. Resolve the fragment identifier (#id) within that file
4. Validate the reference as it currently does for local references

This would make the validator compatible with multi-file GML archives while maintaining backward compatibility with single-file GML documents.

References

• INSPIRE Data Specification on Addresses: Technical Guidelines
• GML Specification (OGC GML 3.2.1, OGC 07-036): OGC GML Standard - Section 7.2.3 "GML properties" defines the "by reference" mode where property values are identified by xlink:href attributes
• XLink 1.1 Specification (W3C Recommendation, 6 May 2010): W3C XLink 1.1 - Section 5.2 "Simple Links" (discusses relative identifier processing according to RFC 3986)
• RFC 3986: URI Generic Syntax - Defines relative URI references and their resolution
• INSPIRE D2.7 Guidelines for the encoding of spatial data: Annex D (Encoding of file-based data) - Discusses GML by-reference mechanism and XLink usage

Thank you for considering this enhancement request. We're happy to provide additional test data or collaborate on testing if needed.

Best regards

[mpleic]

Dear @fabiovinci,

After further investigation and testing with QGIS and GDAL, we have reached a conclusion.

Our Testing Results

We tested our GML files with both QGIS and GDAL (using the GMLAS driver) to understand how these tools handle cross-file references:

1. Local references (#id) - Work correctly within a single GML file
2. Relative path references (./file.gml#id) - Not supported by either QGIS or GDAL
3. Multiple GML files with cross-file references - Neither tool can automatically resolve references between separate files

Our Understanding

After this analysis, we understand that:

• For WFS network services, we use GetFeatureById stored queries with URLs pointing to specific object identifiers for references.
• For ATOM feed distribution (packaged GML files in ZIP archives), the appropriate solution is to package all feature types in a single GML file with local references (#id), rather than splitting them across multiple files.

Our Decision

We are withdrawing our request for support of relative path references within ZIP archives. While the GML, XLink, and INSPIRE specifications may technically allow relative file references, this approach is:

1. Not widely supported by common tools (QGIS, GDAL)
2. Not a standard practice in the INSPIRE community
3. Potentially misunderstood on our part regarding the specification's intent

Our Next Steps

We will explore solutions to package all feature types into a single GML file for ATOM distribution, or maintain our current approach (separate files with local references) if it meets our clients' needs. We understand that our current approach may require clients to merge files manually for validation, which we can document and support.

Conclusion

We appreciate your time and consideration of our request. This issue can be closed from our side. We will adapt our implementation to align with standard practices and tool support.

Thank you again for your assistance.

Best regards