xsd:unsignedLong maps to BigInteger or long

[Fady]

Hello,

I am getting a different mapping for an xsd:unsignedLong depending on the usage of totalDigits or maxInclusive, even though these 2 constraints should be equivalent.

This is the result from xjc:

//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vJAXB 2.1.3 in JDK 1.6
// See http://java.sun.com/xml/jaxb 
// Any modifications to this file will be lost upon recompilation of the source schema.
// Generated on: 2009.11.11 at 01:23:09 PM CET
//


package com.acme.test;

import java.math.BigInteger;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlType;


/**
 * <p>Java class for MyType complex type.
 *
 * <p>The following schema fragment specifies the expected content contained within this class.
 *
 * <pre>
 * <complexType name="MyType">
 *   <complexContent>
 *     <restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *       <sequence>
 *         <element name="elementTotalDigits">
 *           <simpleType>
 *             <restriction base="{http://www.w3.org/2001/XMLSchema}unsignedLong">
 *               <totalDigits value="18"/>
 *             </restriction>
 *           </simpleType>
 *         </element>
 *         <element name="elementMaxInclusive">
 *           <simpleType>
 *             <restriction base="{http://www.w3.org/2001/XMLSchema}unsignedLong">
 *               <maxInclusive value="999999999999999999"/>
 *             </restriction>
 *           </simpleType>
 *         </element>
 *       </sequence>
 *     </restriction>
 *   </complexContent>
 * </complexType>
 * </pre>
 *
 *
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "MyType", propOrder = {
    "elementTotalDigits",
    "elementMaxInclusive"
})
public class MyType {

    @XmlElement(required = true)
    protected BigInteger elementTotalDigits;
    protected long elementMaxInclusive;

    /**
     * Gets the value of the elementTotalDigits property.
     *
     * @return
     *     possible object is
     *     {@link BigInteger }
     *    
     */
    public BigInteger getElementTotalDigits() {
        return elementTotalDigits;
    }

    /**
     * Sets the value of the elementTotalDigits property.
     *
     * @param value
     *     allowed object is
     *     {@link BigInteger }
     *    
     */
    public void setElementTotalDigits(BigInteger value) {
        this.elementTotalDigits = value;
    }

    /**
     * Gets the value of the elementMaxInclusive property.
     *
     */
    public long getElementMaxInclusive() {
        return elementMaxInclusive;
    }

    /**
     * Sets the value of the elementMaxInclusive property.
     *
     */
    public void setElementMaxInclusive(long value) {
        this.elementMaxInclusive = value;
    }

}

Is this the intended behavior? Shouldn't totalDigits="18" and maxInclusive="999999999999999999" yield the same Java type?

Thank you.

Fady

[Wolfgang Laun-2]

On Wed, Nov 11, 2009 at 1:36 PM, Fady <fady@...> wrote:
>
> Hello,
>
> I am getting a different mapping for an xsd:unsignedLong depending on the
> usage of totalDigits or maxInclusive, even though these 2 constraints should
> be equivalent.
>

> Is this the intended behavior? Shouldn't totalDigits="18" and
> maxInclusive="999999999999999999" yield the same Java type?
>

No. Yes.

This behaviour contradicts the JAXB Specification Section 6.2.2,
Atomic Datatype:
Any range limitation of an xs:integer (or derived from this), by a
total digit facet or
by limit facets, should result in the "optimized" representation int or long.

-W

> Thank you.
>
> Fady
> --
> View this message in context: http://old.nabble.com/xsd%3AunsignedLong-maps-to-BigInteger-or-long-tp26300552p26300552.html
> Sent from the java.net - jaxb users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...