[wfs-dev] null values

Chris Holmes cholmes at openplans.org
Fri Oct 27 11:02:58 EDT 2006


I remember this in the first CITE, I had assumed that it would be the 
nillable way, as reading xml schema documents that seemed to be the 
advised way.  But the test engine was made to check to see that no 
elements were returned, not to check the xsi:nil attribute.  I believe 
we had just been returning things in the mapserver way, and that wasn't 
sufficient to pass the tests.

Has MapServer WFS run through the CITE tests?  I believe the CITE tests 
basically provide the answer to questions like these, and they say 
option 2.  As far as I know the CITE tests are definitive on things were 
the spec may be a little unclear, so I would think the answer to the 
question is 2.  Unless I'm wrong about the tests and 1 passes as well.

I do think there's value in the #3 approach, but it's not how the CITE 
project/OGC chose to go about it.

Chris

Bart van den Eijnden (OSGIS) wrote:
> John, list,
> 
> but if I look at:
> 
> http://www.w3.org/TR/xmlschema-0/#Nils
> 
> the preferred way is my approach 3.
> 
> "But in general, the absence of an element does not have any particular
> meaning: It may indicate that the information is unknown, or not applicable,
> or the element may be absent for some other reason. "
> 
> So leaving out an element is clearly not the best way.
> 
> 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
>>
>>
>>
> 
> 
> 
> _______________________________________________
> wfs-dev mailing list
> wfs-dev at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
> 
> !DSPAM:1003,45421c7e142861460912952!
> 

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
Url : http://mail.opengeospatial.org/pipermail/wfs-dev/attachments/20061027/3cf16b32/cholmes.vcf


More information about the wfs-dev mailing list