[wfs-dev] null values

Bart van den Eijnden (OSGIS) bartvde at osgis.nl
Fri Oct 27 10:30:31 EDT 2006


Hi John,

I think XMLSchema deals with this by having the minOccurs as well as the
nillable attribute on an element.

So minOccurs="1" nillable="false" would mean NOT NULL.

Best regards,
Bart

--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl


--------- Oorspronkelijk bericht --------
Van: John Herring <john.herring at oracle.com>
Naar: 'Bart van den Eijnden OSGIS' <bartvde at osgis.nl>,
wfs-dev at opengeospatial.org <wfs-dev at opengeospatial.org>
Onderwerp: RE: [wfs-dev] null values
Datum: 27/10/06 11:36

> Bart, 
> 
> 	Most systems have their own way of dealing with
> NULLs. In XML is seems to be simply leaving out the element.
> Which leads to an interesting philosophic question about
> your proposal.  
> 
> 	If one writes:
> 
> &lt;MYFIRSTITEM&gt;aaa&lt;/MYFIRSTITEM&gt;
> &lt;PRIORITY/&gt;
> &lt;MYTHIRDITEM&gt;zzz&lt;/MYTHIRDITEM&gt;
> 
> 	And the original schema calls for PRIORITY's
> minOccurs to be 1, have you violated the intent of the
> schema? In SQL you get to put in &quot;NOT NULL&quot; and in XML you
> get to put in &quot;minOccurs=1&quot; and force a value. In either of
> your suggestions with a PRIORITY element, you are not in
> violation of a  &quot;minOccurs=1&quot; but you are in violation of
> the semantics of not allowing a NULL. 
> 
> 	Personally, I thing that IONIC is right and the only
> way to do this is the way the XML gurus meant us to do it,
> which is with minOccurs=0 and missing elements. On the other
> hand, GML's multiple  flavors of NULL does something else
> altogether, but at least you can force an application schema
> not to use it (the equivalent of a NOT NULL). 
> 
> Regards,
> John
> 
> You do what you can when you can because you can. 
> 
> The opinions expressed in this email are purely my own and
> do not necessarily represent the opinions of any
> organization
> or otherwise sane person or persons.
> 
> John R. Herring
> Architect, Spatial Products
> Oracle Corporation
> One Oracle Drive
> Nashua, New Hampshire 03062
> ph: 1 603 897 3216
> fx: 1 603 897 3334
> 
> Annue cœptis - Novus Ordo Seclorum
> 
> 
> -----Original Message-----
> From:
> wfs-dev-bounces+john.herring=oracle.com at opengeospatial.org
> [mailto:wfs-dev-bounces+john.herring=oracle.com at opengeospati
> al.org] On Behalf Of Bart van den Eijnden (OSGIS)
> Sent: Friday, October 27, 2006 9:06 AM
> 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)
> 
> &lt;MYFIRSTITEM&gt;aaa&lt;/MYFIRSTITEM&gt;
> &lt;PRIORITY&gt;&lt;/PRIORITY&gt;
> &lt;MYTHIRDITEM&gt;zzz&lt;/MYTHIRDITEM&gt;
> 
> I think this is how Mapserver WFS operates.
> 
> 
> 2)
> Leave out the respective element in the reponse.
> 
> &lt;MYFIRSTITEM&gt;aaa&lt;/MYFIRSTITEM&gt;
> &lt;MYTHIRDITEM&gt;zzz&lt;/MYTHIRDITEM&gt;
> 
> This is what Ionic WFS does.
> 
> 3)
> An option I have not yet seen, output xsi:nil=&quot;true&quot; for the
> respective element?
> 
> &lt;MYFIRSTITEM&gt;aaa&lt;/MYFIRSTITEM&gt;
> &lt;PRIORITY xsi:nil=&quot;true&quot;&gt;&lt;/PRIORITY&gt;
> &lt;MYTHIRDITEM&gt;zzz&lt;/MYTHIRDITEM&gt;
> 
> 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