[sf-perl] Some well-formed XML?

Andrew Sigmund ASIGMUND at altera.com
Thu Sep 22 10:06:45 PDT 2005


Josh,

Oops: I neglected to respond to your other points.

>> My general inclination would be to treat all ZLS as NULLs in the 
>> database, unless I have a specific reason to do otherwise or unless the 
>> value is defined as "required" in the DTD.
For "required" columns, every row must have a value, so NULLs don't exist by definition, and a ZLS is always just that, a ZLS.  
For non-"required" columns, we must be able to distinguish between an empty string (ZLS) and a NULL.  This may be your "specific reason to do otherwise".  For some applications, treating the absence of a value (a NULL) as a ZLS is OK, but for other applications, the difference can be significant.  A NULL does not indicate "nothing" (as an empty string does for a string or 0 does for a number; it indicates that the value is unknown (or not applicable).


I am not familiar with the CPAN module for SQL-->XML conversion.

Andy


-----Original Message-----
From: sanfrancisco-pm-bounces at pm.org [mailto:sanfrancisco-pm-bounces at pm.org] On Behalf Of Andrew Sigmund
Sent: Thursday, September 22, 2005 09:43
To: San Francisco Perl Mongers User Group
Subject: Re: [sf-perl] Some well-formed XML?

Josh,

>> Are XML parsers going to treat (2) any differently from (3), though?

Good question.  I'm more a database guy than an XML guy.  
Those examples were from my "alternate" solution.  I still believe that the best (only?) solution involves something external to the value itself to tell you that no value exists (that is, is NULL), and that attempts to kludge some sort of flag value to tell you whether or not the value actually exists (is NULL or not) is akin to inserting a Hydra's head into the design.

Examples (for the original proposal):

ColumnB is not NULL and not an empty string:
<ColumnB><IsNULL>FALSE</IsNULL><Value>MyString</Value></ColumnB>

ColumnB is not NULL, but an empty string:
<ColumnB><IsNULL>FALSE</IsNULL><Value></Value></ColumnB>

ColumnB is NULL:
<ColumnB><IsNULL>TRUE</IsNULL><Value></Value></ColumnB>


>> Also, what about data types which don't support zero-length-strings 
>> (ZLS), like dates?

I'm not sure I understand the question.  (Perhaps due to my naïve understanding of XML.)  In (modern) databases, a column of any data-type should be NULLable.  The parser should attempt to decode (or encode) the value string enclosed by <Value></Value> only when IsNULL is FALSE.

Andy

-----Original Message-----
From: sanfrancisco-pm-bounces at pm.org [mailto:sanfrancisco-pm-bounces at pm.org] On Behalf Of Josh Berkus
Sent: Thursday, September 22, 2005 09:11
To: San Francisco Perl Mongers User Group
Subject: Re: [sf-perl] Some well-formed XML?

Andrew,

> Example:
> ColumnB is not null and not empty:
> <ColumnA>123</ColumnA><ColumnB>MyString</ColumnB><ColumnC>456</ColumnC>
> 
> ColumnB is not null, but is an empty string:
> <ColumnA>123</ColumnA><ColumnB></ColumnB><ColumnC>456</ColumnC>
> 
> ColumnB is null:
> <ColumnA>123</ColumnA><ColumnC>456</ColumnC>

Are XML parsers going to treat (2) any differently from (3), though? 
That is, if I hand an XML application (2), might it return (3) instead 
or vice-versa?

Also, what about data types which don't support zero-length-strings 
(ZLS), like dates?

My general inclination would be to treat all ZLS as NULLs in the 
database, unless I have a specific reason to do otherwise or unless the 
value is defined as "required" in the DTD.

Anyway, this is *terrific* food for thought.  BTW, what was the name of 
the CPAN module for SQL-->XML conversion which was demoed at SFPerl 
abotu 6months ago?

--Josh
_______________________________________________
SanFrancisco-pm mailing list
SanFrancisco-pm at pm.org
http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


_______________________________________________
SanFrancisco-pm mailing list
SanFrancisco-pm at pm.org
http://mail.pm.org/mailman/listinfo/sanfrancisco-pm




More information about the SanFrancisco-pm mailing list