Re: dateTime.iso8601 format

>Again, I'm using the Perl module RPC::XML and it includes a way to
>force all data into a <string>.  I kind of wished I used that
>approach. ;)  I could just say "foo" is of type string and represents
>a timestamp in this format, including the "Z" and all would be well.

And if you really want flexibility, skip the whole XML-RPC spec and
all the XML-RPC software and just send your data in an HTTP request of
your own design.  So it's all about how much value you want to squeeze
from an XML-RPC library.  Having the dateTime.iso8601 standard makes
it possible to have an XML-RPC library do the work of interpreting the
datetime, but if the library in question just hands you the raw text
from the XML-RPC document, you're not getting any value out of the
type.

But tell me more about RPC::XML: in the mode where it _doesn't_
present everything as a <string>, how do you see the
<dateTime.iso8601> value?  Still as the raw text?  And if not, what
happens with <dateTime.iso8601>today</dateTime.ios8601>?  If I were
doing an XML-RPC application in Perl, I'd want to see it as the same
thing that time() returns (seconds-since-epoch).

>>> >Is that an empty string or undefined/null string?
>>> 
>>> I think it's clear that it has to be an empty string (zero length
>>> string) because such strings are normal and this is the obvious (and
>>> only) way to represent one.
>
>I'm not sure it's that clear.  A value in a database can be NULL or an
>empty string and sometimes you need to know the difference.

Maybe it's just a meaningless question at the XML-RPC level.  Maybe
the distinction between empty and NULL is something that has to be
designed in the entity that converts between XML-RPC and another
representation (e.g. Perl variables or database fields).  You clearly
have to choose; XML-RPC isn't rich enough to represent both an empty
string and a NULL one, but if it makes sense in some context for
<string></string> to correspond to a NULL field in a database, and
have no way to represent an empty string field, I don't think there's
any reason not to write the XML-RPC application that way.

All I'm really saying about normalcy is that I'll bet given the
choice, most users of an XML-RPC library would demand empty string;
e.g. a Perl RPC:XML user wants to see '', not undef.

-- 
Bryan Henderson                                   San Jose, California

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/xml-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/