SQL Query explicitly as defined by User

We've observed many cases where Report Builder's interpretation of the instructed query logic is erroneous with SQL forcing us to continue using SPARQL until these issues are resolved. 

NOTE: This issue is all the more urgent after learning SPARQL will no longer be available effective 7.2.

An example of this is in ASSUMING when we want to filter against a Boolean value = False, the desire for the inclusion of <Blank/Null> (i.e. Report Builder will return all values whereby the Attribute = False || Attribute = <Blank/Null> (i.e. unpopulated.

As seen in the IBM support Ticket referenced herein, the support agent described the current behavior as an intentional design decision, which by extension makes it a design flaw because:

Rationale quoted by Service representative's response: “The attribute MAY be defined with a default value (False).”

MAY is assumptive in your usage; the User MAY also NOT!

If it were to behave EXACTLY as we explicitly define it, the User can address both the case where False is the default (and thus <blank/null> is to be interpreted as False), and the case where False is NOT the default (i.e. False is to be treated separate and distinctly from <blank/null>. Your implementation of the query depends on the OBLIGATION of False as default (and equivalent to <blank/null>, which is inconsistent with being provided the option to set or NOT set a default value as need be.

That a default value is rightfully NOT an obligation when defining an Attribute means the logic in Report Builder OBLIGING its ASSUMPTION, is NOT consistent with fitness of purpose of Use (that is, to be able to define the logic WE deem fit, not the logic IBM OBLIGE by ASSUMPTION. Never assume…

i.e. If I wanted to filter for values of False || <Blank/Null>, I'll design my report with this logic explicitly as the filter; and by extension, if I design a report for Boolean Attribute = False, Report Builder should interpret the logic as exclusively where the value = False, EXCLUDING <Blank/Null>.