From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id A7A76BC6B for ; Sun, 19 Aug 2007 20:29:46 +0200 (CEST) Received: from tenhost.net (tenhost.net [64.246.28.52]) by discorde.inria.fr (8.13.6/8.13.6) with SMTP id l7JITike011306 for ; Sun, 19 Aug 2007 20:29:46 +0200 Received: (qmail 4199 invoked from network); 19 Aug 2007 13:02:30 -0500 Received: from ip72-208-52-84.ph.ph.cox.net (HELO ?192.168.1.99?) (72.208.52.84) by tenhost.net with SMTP; 19 Aug 2007 13:02:30 -0500 Message-ID: <46C88BEF.4070400@ramenlabs.com> Date: Sun, 19 Aug 2007 11:29:03 -0700 From: Dave Benjamin User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: caml-list@inria.fr Cc: =?windows-1252?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] ANN: XmlRpc-Light 0.4 - Now a server too References: <46ACD395.4080609@ramenlabs.com> <20070729211615.GA25630@furbychan.cocan.org> <46AD1E22.6080705@ramenlabs.com> <912A68A9-3C5A-44FC-B563-4033E4EE6235@epfl.ch> In-Reply-To: <912A68A9-3C5A-44FC-B563-4033E4EE6235@epfl.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 46C88C18.005 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 parser:01 subset:01 bug:01 pointer:01 ocamllex:01 0.4:98 wrote:01 parsing:01 caml-list:01 conflicts:01 func:01 benjamin:01 benjamin:01 writes:01 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