Version française
Home     About     Download     Resources     Contact us    
Browse thread
ANN: XmlRpc-Light 0.4 - Now a server too
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Dave Benjamin <dave@r...>
Subject: Re: [Caml-list] ANN: XmlRpc-Light 0.4 - Now a server too
Daniel Bünzli wrote:
> Le 30 juil. 07 à 01:09, Dave Benjamin a écrit :
>> I really wish Winer had considered alternatives to ISO 8601--say, UTC 
>> epoch seconds--in the design of XML-RPC, because it's barely a 
>> standard at all! There are so many variations and options that writing 
>> a parser for it borders on natural language processing. Even the W3C 
>> suggestion, which restricts ISO 8601 to a very small subset, doesn't 
>> help here since it still conflicts with the common usage in XML-RPC, 
>> with hyphens omitted between the date values.
> 
> Very unfortunate. He should have at least used RFC 3339 [1], which is 
> akin to the W3C NOTE-datetime suggestion but a little more formal.

Even worse, despite the fact that the tag name is "dateTime.iso8601", 
the XML-RPC "specification" only allows one official format:

YYYYMMDDTHH:MM:SS

The wording is vague, but it's clarified here:
http://www.effbot.org/zone/xmlrpc-errata.htm

"The time value is “naive time”, and does not include a timezone. You 
can either use a fixed timezone in your application (such as UTC), or 
ship the timezone offset as a separate value."

In other words, even though ISO 8601 clearly indicates *several* ways of 
specifying a timezone, none are allowed by a standards conforming 
XML-RPC library. As many have pointed out, a date-time value with no 
time zone is useless, and assuming every server is using UTC is really 
just wishful thinking.

In XmlRpc-Light, the default implementation reads and writes the format:

YYYYMMDDTHH:MM:SS+TZ:TZ

with the time zone offset optional on parsing, and mandatory on 
generation. This seems to work everywhere but Ruby, where there exists 
code to parse the time zone, but it apparently hasn't been tested in 
awhile because it's broken. It's simple to fix, and I submitted a bug 
report about it:

http://rubyforge.org/tracker/index.php?func=detail&aid=12677&group_id=426&atid=1698

So, now I'm faced with this dilemma:

Option A: Change XmlRpc-Light's default date-time handling to conform to 
the XML-RPC spec. Interoperability with Ruby will work by default, but 
time zone offsets will all be zero unless the programmer provides an 
alternate, fancier date-time encoder/decoder.

Option B: Leave it alone. Time zone offsets will continue to work by 
default. Ruby interoperability will not work without a code change on 
one side or the other, at least until (and if) the Ruby team applies my 
patch. Existing Ruby installations will be broken. XmlRpc-Light will be 
considered non-conforming.

> I point you to this RFC because appendix A contains a tentative ABNF 
> definition of ISO 8601 you may be interested in looking at.
> [1] http://www.ietf.org/rfc/rfc3339.txt

Thanks for the pointer. It's nice to see this explained so formally. 
Maybe now would be a good time for me to learn how to use ocamllex.

Regards,
Dave