W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

Re: NEW ISSUE: Schema tweaks

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>
Message-ID: <Pine.LNX.4.44L0.0503011919040.1616-100000@smtp.datapower.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT