European Commission logo
INSPIRE Community Forum

Contents of attribute nilReason (e.g. unknown vs: http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unknown)

I have a question concerning the contents of attribute nilReason. This attribute must be filled out when xsi:nil=”true”, that is, when a property is void.

Description of the issue

The allowed values in INSPIRE are defined on http://inspire.ec.europa.eu/codelist/VoidReasonValue/

In almost all examples I’ve seen, also in the INSPIRE data specifications themselves, it is filled out like this (sometimes are unknown, unpopulated, etc. capitalized, sometimes not).

<myAttribute xsi:nil="true" nilReason="unknown"/>

<myAttribute2 xsi:nil="true" nilReason="unpopulated"/>

According to the GML specification, which specifies attribute nilReason, the type of attribute nilReason must be one of the following:

  • gml:NilReasonEnumeration
  • anyURI

A value conformant to gml:NilreasonEnumeration must be one of the following:

  • inapplicable
  • missing
  • template
  • unknown
  • withheld
  • other:<briefExplanation>

A value conformant to anyURI represents a Uniform Resource Identifier Reference (URI), see also http://www.w3.org/TR/xmlschema-2/#anyURI. The meaning of a URI in the context of nilReason is “a resource which describes the reason for the exception. A particular community may choose to assign more detailed semantics to the standard values provided. Alternatively, the URI method enables a specific or more complete explanation for the absence of a value to be provided elsewhere and indicated by-reference in an instance document.

Interesting on http://www.w3.org/TR/xmlschema-2/#anyURI is the following note:

Note:  Each URI scheme imposes specialized syntax rules for URIs in that scheme, including restrictions on the syntax of allowed fragment identifiers. Because it is impractical for processors to check that a value is a context-appropriate URI reference, this specification follows the lead of [RFC 2396] (as amended by [RFC 2732]) in this matter: such rules and restrictions are not part of type validity and are not checked by ·minimally conforming· processors. Thus in practice the above definition imposes only very modest obligations on ·minimally conforming· processors.

This means most XML validators will accept the following GML, although it is not conformant to the GML specification, since it is not a URI and does not belong to the values defined in gml:NilreasonEnumeration:

<myAttribute2 xsi:nil="true" nilReason="unpopulated"/>

The following options would be conformant:

<myAttribute2 xsi:nil="true" nilReason="other:unpopulated"/>

<myAttribute2 xsi:nil="true" nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unpopulated"/&gt;

Note also that the values defined in http://inspire.ec.europa.eu/codelist/VoidReasonValue/ were not present in the INSPIRE registry until some time in 2015.

My question

What are we supposed to use in INSPIRE data sets?

Option 1: continue as we have been doing, but using other:unpopulated instead of unpopulated, in order to be conformant with the GML specification.

<myAttribute xsi:nil="true" nilReason="unknown"/>

<myAttribute2 xsi:nil="true" nilReason="other:unpopulated"/>

<myAttribute xsi:nil="true" nilReason="withheld"/>

Option 2: change to the URI's as defined in the INSPIRE registry.

<myAttribute xsi:nil="true" nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unknown"/&gt;

<myAttribute2 xsi:nil="true" nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unpopulated"/&gt;

<myAttribute xsi:nil="true" nilReason="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Withheld"/&gt;

Option 3: no common guidelines/practice

  • Heidi VANPARYS

    By Heidi VANPARYS

    Additional note: I discussed this issue with Clemens Portele, the following is quoted from his reply:

    [...]

    There is another aspect. In earlier versions of GML we required that every unit in a uom attribute is the URI of a unit definition. However, what happended in practice that many were using symbols like "m" instead as they are shorter and often even better understood (compared to http://www.opengis.net/def/uom/EPSG/0/9001). Therefore we changed this in GML 3.2 to allow also symbols (typically UCUM is used for the symbols). I could see that perhaps a similar preference exists for the nilReason values, in particular as two of the values are already pre-defined in GML. I.e., there could also be an argument for continuing to use the values

    • unknown
    • other:unpopulated
    • withheld

    in the nilReason attributes.

    I do not see an issue about the use of lower/upper case. The semantics are compatible for unknown and withheld and both are the GML implementation of Unknown and Withheld.

    [...]

    Now that there are two options (gml:NilReasonEnumeration or URI in INSPIRE registry) I guess it would be a good idea, if the MIG provides guidance (and updates D2.7 to include the guidance as a recommendation).