>From that description, it sounds like we really need PropertyIsNull (which >we're using right now), not PropertyIsNil, since "PropertyIsNull results in >true, if the WFS would return the feature without any property element ><tns:p>". We're testing for the presence or absence of an element, not an >element with xsi:nil="true"... Yet, with that explicit instanceof check for >ComplexAttribute, PropertyIsNull always returns true...
-----Original Message----- From: Jody Garnett [mailto:[email protected]] Sent: Sun 10/2/2011 4:26 AM To: Dustin Parker Cc: Geotools-Devel list Subject: isNil vs isNull Dustin here is the part that reflects on isNull vs isNil. > > And here is the issue that has the attached patch: > > http://jira.codehaus.org/browse/GEOT-3657 > > * PropertyIsNil > > Filter (FES) 2.0 adds a new filtering construct named PropertyIsNil. To be > > honest I am still a bit fuzzy on what this is actually supposed to do. > > However I did get some clarification from wfs-dev list: > > > > > > assume you have a GML feature type which has a property p where the > > > property element is declared with minOccurs="0" and nillable=true. > > > PropertyIsNull results in true, if the WFS would return the feature > > > without any property element <tns:p>. > > > PropertyIsNil results in true, if the WFS would return the feature with a > > > property element <tns:p xsi:nil='true'>. This can be refined using the > > > nilReason parameter. > > > > And as it turns out i completely misinterpreted the spec... so my > > implementation of PropertyIsNil doesn't match that at all :) However I am > > not sure how to implement it property... our filter model doesn't have any > > notion of schema like this requires. Anyways, in the end all the client > > wanted to click a check box, and not really to do anything with it so i > > never went back and revisited. > > Here is the patch I came up with though: > > http://jira.codehaus.org/browse/GEOT-3870 > > I am tempted to simply just have PropertyIsNil be an alias for > > PropertyIsNull at this point... and when someone has a mandate to implement > > it properly they can do so. Thoughts? > > Hummm.. I have the impression that this might be solved with a single > null checking operation plus a check on the flag that drives the xml > encoding. > If the encoder is always skipping the elements that have null value: > - PropertyIsNull would behave like today, true if the value is null, > false otherwise > - PropertyIsNil would always return false, it's either not null, and > if it is we are not returning the element anyways > If the encoder is always encoding the element with the nil flag, it's > the opposite. > > So, I have the impression that a filter transformer knowing how a null > value element is going to be encoded can be used > to turn the filter in either what we have today, or Filter.Exclude ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
