[wfs-dev] null values

Clemens Portele portele at interactive-instruments.de
Mon Oct 30 05:27:54 EST 2006


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



More information about the wfs-dev mailing list