W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2004

Re: [ht@inf.ed.ac.uk: Re: [xml-dev] RE: Schema vs Schema-free]

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 14 Apr 2004 17:43:14 -0400
To: jcowan@reutershealth.com
Cc: www-xml-schema-comments@w3.org, MFC@uk.ibm.com
Message-ID: <OF48087AD4.F25FDF6E-ON85256E76.00761FBC@lotus.com>

Well, it's worth noting that the proposed type is in fact intended to 
support the emerging IEEE standard (IEEE 854 ... I don't have official 
links but unofficial text is at [1]).  This is also essentially the same 
type supported by java.math.BigDecimal [2].  While there's some discussion 
ongoing regarding the nuances, it is also either very close to or an exact 
match to .Net system.Decimal [3].   All of these distinguish "4" from 
"4.0" and in turn from "4.00".   (Specifically these are {value=4, 
scale=0}, {value=40, scale=1} and {value=400, scale=2} respectively.) 

IBM is supporting IEEE decimal in a range of software products (not just 
Java) as well as in some hardware implementations, and we anticipate that 
other vendors will do the same.  In short, we expect that, like IEEE 754, 
this type will have great significance as an industry standard.  Indeed, 
we believe that XML Schema made a mistake in adopting the original 
xsd:decimal and that there will be significant benefits to supporting the 
IEEE standard type in XML Schema.

FWIW:  I suggest that any futher discussion be moved to the Schema IG 
list, as we normally use the comments list just to gather and frame 
issues.

Noah

[1] 
http://www.cs.berkeley.edu/~ejr/projects/754/private/drafts/854-1987/854-1987.pdf
[2] http://java.sun.com/j2se/1.4.2/docs/api/index.html
[3] 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdecimalclasstopic.asp

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








jcowan@reutershealth.com
Sent by: www-xml-schema-comments-request@w3.org
04/14/2004 05:13 PM

 
        To:     www-xml-schema-comments@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        [ht@inf.ed.ac.uk: Re: [xml-dev] RE: Schema vs Schema-free]



On xml-dev, Henry S. Thompson wrote:

> The W3C XML Schema Working Group is considering a proposal to add a
> datatype to the next version of W3C XML Schema which would distinguish
> e.g. 3.0 from 3.00 _as values_.  Reasoned statements of support or
> disagreement would be very welcome on www-xml-schema-comments@w3.org

I oppose this.  Mathematically, the numerals "3.0" and "3.00" are the same
thing, representations of the number 3.  People who make distinctions
between them are really trying to use using a single numeral to express
an *interval* value, most typically [2.95, 3.05) versus [2.995, 3.005).
(The [ marks an inclusive interval bound, the ) marks an exclusive one.)

What is worse, this convention works only for interval sizes less than 1.
There is no telling, given the numeral "1000", whether the intended
interval size is [500, 1450), [950, 1050), [995, 1005), or [999.5, 100.5).

Rather than supporting this hack, it would be more appropriate to add
proper support for intervals.  If people can convert their date data to
ISO 8601, they can convert their "significant figures" numbers to proper
interval values with a lower bound (inclusive or exclusive) and an upper
bound (inclusive or exclusive).

-- 
John Cowan  www.ccil.org/~cowan  jcowan@reutershealth.com 
www.reutershealth.com
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday 
he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no 
ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini
Received on Wednesday, 14 April 2004 17:44:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:34 UTC