- From: Steve Schafer <steve@fenestra.com>
- Date: Mon, 04 Oct 2010 12:53:23 -0400
- To: Paul Williams <pwilliams@infotrustgroup.com>
- Cc: www-svg <www-svg@w3.org>
On Mon, 4 Oct 2010 08:25:23 -0700, you wrote: >A NULL column in a database could mean something different than a zero >length string... While I agree with the sentiment, you are undermined by your own example. In Oracle, for example, in the following query: select foo from bar where baz is null an empty string passes the "is null" test. >...depending on the business rules at hand. Ah, that gets to the heart of the matter. The business rules aren't in the data, they're in the schema. And the same is true in XML. Using a DTD, for example, you can declare an element to be EMPTY, and thereby distinguish between an element that is _defined_ to be empty and one that _happens_ to be empty. But that still doesn't help you in the ternary case, if you need to distinguish among null, empty string, non-empty string. I have encountered situations where it was necessary to distinguish "something" (e.g., a numerical value) from "nothing," but I've never encountered a situation where it was necessary to distinguish an empty string from a null, because when something like that arises, I use a separate boolean field to indicate "nullness." The US Census Bureau, for example, handles a similar problem by dividing a value response field into two parts, one where you enter a number and another "check if none" checkbox that you use to indicate that there is no meaningful value. That way, they can distinguish between the respondent answering the question with the equivalent of N/A (empty value) vs. not answering the question at all (null value). Steve Schafer
Received on Monday, 4 October 2010 16:54:29 UTC