- From: Rich Salz <rsalz@datapower.com>
- Date: Tue, 1 Mar 2005 19:27:34 -0500 (EST)
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, Jonathan Marsh <jmarsh@microsoft.com>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>, "public-ws-addressing-request@w3.org" <public-ws-addressing-request@w3.org>, "Rogers, Tony" <Tony.Rogers@ca.com>
> Patient: Hey doc, it hurts when I use an xs:duration of 1M1D because it
> depends on what month it is
> Doctor: Don't do that!
Okay, I'll use a duration of one minute and hope it doesn't have
leap-seconds. Or hope that I'm not transiting the end of February,
because then I need to know about leap years. There's just too
many special cases.
It's a fundamental problem with xs:duration -- it is only valid in a
particular timeframe. You can't say "try xxx later" without knowing
what *now* is. Saying "don't do that" tries to ignore the issue.
> Sure, an xs:unsignedLong that represents milliseconds *seems* simpler
> until you get into squirrelly areas
> like the fact that Java does not have a primitive type for xs:unsignedLong
> which means you need to
> manipulate it with java.math.BigDecimal which is not very efficient.
This brings up a host of replies. First, this is yet another
reason to favor unsignedInt. Second, I don't particularly care about
Java's problems with integers. Third, do you care about forcing
me to now understand a fairly complex XSD datatype now?
xs:duration is on the wrong side of 80/20. The way wrong side.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
Received on Wednesday, 2 March 2005 00:27:43 UTC