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.