aspose file tools*
The moose likes XML and Related Technologies and the fly likes xsd for BigDecimal Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » XML and Related Technologies
Bookmark "xsd for BigDecimal" Watch "xsd for BigDecimal" New topic

xsd for BigDecimal

Mary Joe

Joined: Jun 17, 2010
Posts: 20

Can some one please explain the meaning <xs:restriction base="xs:decimal"> ...</xs:restriction> in the pasted xsd snippet

I want to create a new element of jaxb javatype java.math.Bigdecimal

How will I determine xs:totalDigits value="?"/>
<xs:fractionDigits value="?"/>
<xs:minInclusive value="?"/>

The data that comes in the xml format get persisted to a database table column of type NUMBER(13,2)

<xs:element name="salaryamount">
<jaxb:property name="SalaryAmount"/>
<jaxb:javaType name="java.lang.Double" parseMethod="valueOf" printMethod="toString"/>
<xs:restriction base="xs:decimal">
<xs:totalDigits value="10"/>
<xs:fractionDigits value="2"/>
<xs:minInclusive value="0"/>
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 544
I want to create a new element of jaxb javatype java.math.Bigdecimal

How will I determine xs:totalDigits value="?"/>
<xs:fractionDigits value="?"/>
<xs:minInclusive value="?"/>

The restrictions on fractionDigits and totalDigits are determined by three considerations:
[1] The map between xsd xs:decimal type, and
[2] db's column data type NUMBER(n,m), and
[3] The customized java data type being Double or BigDecimal (or any other pertinent admissible types).

The object should be making them co-exist without contradition so that the eventual ORM be feasible.

If you look into what you have when it maps to java data type of Double, the column data type is NUMBER(13,2) being of precision 13 (more or less the equivalent xs:totalDigits) and a scale of 2 (more or less xs:fractionDigits 2). If the author knows the data stored in the column are all positive (including 0) and that the number would not be as big to attain the max permissible integer of 13 digits, he must have been comfortable to that restriction of xs:totalDigits=10 and xs:fractionDigits 2 adding minInclusive to reflect the positive definit data. On the java data type side of the consideration, java.lang.Double can certain hold that range of decimal. Furthermore, xs:decimal in the w3c recommendation is kind of more flexible, but a minimum of 18 total digits is recommended for a minimally conformed schema-aware processor. Hence, overall, the design should then be workable for most cases.

However, if you want to customize the mapping to java.math.BigDecimal, the precision and scale it is admissible is not limited. BigDecimal is more potent than Double. Hence, the detemining factor of common denominator of the overall design is still fallen on the column data type NUMBER(13,2). Hence, the logical decision to make is just to keep the restrictions the same and that would be fine unless you have other considerations.

Take for instance, if you impose xs:totalDigits being 25 (arbitrary), that exceeds the requirement of minimally compliant processor the recommendation is suggesting, then first the processor might not even honour it and second the column data type would not hold the data neither... so that the whole exercise would be very unrealistic.

That is what I would say in consideration of such issue.
wood burning stoves
subject: xsd for BigDecimal