[wfs-dev] null values

[Simon.Cox@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.org
> [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