[wfs-dev] null values

Mon Oct 30 17:34:44 EST 2006

The documentation for the urn:x-ogc:def:nil branch is within "Definition identifier URNs in OGC namespace" avialable from http://www.opengeospatial.org/standards/bp. 
The usage pattern is only implied, but I think it is reasonably elegant, since it leverages the existing GML property pattern, and does not require you to have to remember to make properties "nillable" in the schema and also add the "nilReason" attribute. 

It may be time for a short "Best Practice" paper on nil/null values in GML data. 
At least enuerating these various options. 
I believe the list goes something like this:

   * element omitted (semantics implied/obscure)
   * empty element, not nilled (probably invalid, except for string types)
   * empty element with nil="true" (schema designer must remember to allow this)
   * empty element with nil="true" and nilReason (ditto, more)
   * nil urn in the xlink:href (applicable to all "by reference" properties, but not available for simpleContent)

Simon

-----Original Message-----
From: wfs-dev-bounces+simon.cox=csiro.au at opengeospatial.org [mailto:wfs-dev-bounces+simon.cox=csiro.au at opengeospatial.org] On Behalf Of Andreas v.Dömming
Sent: Monday, 30 October 2006 8:33 PM
To: wfs-dev at opengeospatial.org
Subject: Re: [wfs-dev] null values

Hi Simon,

Where are OGC specific URNs defined ? Can you point me to some documentation ?
Thanks in advance,

Regards,
 Andreas

Am Montag, 30. Oktober 2006 13:02 schrieb Simon.Cox at csiro.au:
> Another relative clean option for all GML properties that allow the 
> "by-ref" option (xlinks) is to set the value of 
> xlink:href="urn:x-ogc:def:nil:OGC:unknown" etc.
>
> The OGC URN schema "def" branch supports all the GML nulls.
> This is *not* the "XML Schema" way (that would use option 3 and as 
> Clemens points out is specified in GMl 3.2).
> But it is perhaps more general and less messy in the schema - it 
> applies to all props *except* the simpleContent props.
> (which I realise are the most common in App Schemas in the wild).
>
> Simon
>
>
> -----Original Message-----
> From: wfs-dev-bounces+simon.cox=csiro.au at opengeospatial.org
> [mailto:wfs-dev-bounces+simon.cox=csiro.au at opengeospatial.org] On 
> Behalf Of Clemens Portele
> Sent: Monday, 30 October 2006 6:28 PM
> To: 'Bart van den Eijnden (OSGIS)'; wfs-dev at opengeospatial.org
> Subject: Re: [wfs-dev] null values
>
> Hi Bart,
>
> As you point out, 1. is an empty string (assuming that the type of 
> PRIORITY is string) which is not a NULL. Besides this approach does 
> not work at all for numbers or most other data types.
>
> 2. is the representation that has been used in most GML application 
> schemas that I have seen and that is the result of the default mapping 
> from UML multiplicities for attributes and relationship roles as 
> specified in ISO
> 19118 as well as GML.
>
> The Simple Features profile of GML has a discussion about Null values 
> and specifies that option 2 is to be used in this profile.
>
> 3. is in general also a possibilty. In ISO/DIS 19136 (GML 3.2.0) 
> nillable is explicitly mentioned: "Declaring an element to be nil is 
> an implementation of the "Void" datatype of ISO/IEC 11404, i.e. 
> represents 'an object whose presence is syntactically or semantically 
> required, but carries no information in a given instance' [ISO/IEC 
> 11404]." nillable is useful in particular in conjunction with a 
> nilReason attribute (which allows to attach reason metadata to a void 
> - nil elements may carry attributes but no other
> content) for those application schemas that want to make use of such a 
> construct. However, there are issues with the use of nillable. That it 
> cannot be used with "ref" has been mentioned by John, i.e. in most 
> cases nillable is appropriate only in properties in application 
> schemas that are represented by local elements (which is the standard 
> mapping for properties from ISO 19109 application schemas in UML). 
> Another is that this construct is not an XML mechanism per se, but XML Schema specific.
>
>
> Clemens
>
> > -----Original Message-----
> > From:
> > wfs-dev-bounces+portele=interactive-instruments.de at opengeospatial.or
> > wfs-dev-bounces+g
> > [mailto:wfs-dev-bounces+portele=interactive-instruments.de at ope
> > ngeospatia
> > l.org]On Behalf Of Bart van den Eijnden (OSGIS)
> > Sent: Friday, October 27, 2006 3:06 PM
> > To: wfs-dev at opengeospatial.org
> > Subject: [wfs-dev] null values
> >
> >
> > Hi list,
> >
> > how is a WFS supposed to deal with null values?
> >
> > I can see 3 options (for instance an attribute named PRIORITY):
> >
> >
> > 1) just output an empty element (I guess not the cleanest approach 
> > since it cannot be distinguished from an empty string)
> >
> > <MYFIRSTITEM>aaa</MYFIRSTITEM>
> > <PRIORITY></PRIORITY>
> > <MYTHIRDITEM>zzz</MYTHIRDITEM>
> >
> > I think this is how Mapserver WFS operates.
> >
> >
> > 2)
> > Leave out the respective element in the reponse.
> >
> > <MYFIRSTITEM>aaa</MYFIRSTITEM>
> > <MYTHIRDITEM>zzz</MYTHIRDITEM>
> >
> > This is what Ionic WFS does.
> >
> > 3)
> > An option I have not yet seen, output xsi:nil="true" for the 
> > respective element?
> >
> > <MYFIRSTITEM>aaa</MYFIRSTITEM>
> > <PRIORITY xsi:nil="true"></PRIORITY> <MYTHIRDITEM>zzz</MYTHIRDITEM>
> >
> > Ofcourse the 1) and 3) behaviour is easier to process (for instance 
> > with
> > XSLT) than the second one.
> >
> > Should the WFS spec say something about this? Or is it up to the 
> > vendor? It would make life easier if they all did the same thing IMHO.
> > And I guess 3)
> > is the cleanest approach.
> >
> > Thanks in advance for any input on this.
> >
> > Best regards,
> > Bart
> >
> > --
> > Bart van den Eijnden
> > OSGIS, Open Source GIS
> > http://www.osgis.nl
> >
> >
> >
> >
> >
> > _______________________________________________
> > wfs-dev mailing list
> > wfs-dev at opengeospatial.org
> > https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
>
> _______________________________________________
> wfs-dev mailing list
> wfs-dev at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
>
> _______________________________________________
> wfs-dev mailing list
> wfs-dev at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
_______________________________________________
wfs-dev mailing list
wfs-dev at opengeospatial.org
https://mail.opengeospatial.org/mailman/listinfo/wfs-dev