Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4959151

javax.xml.datatype classes should follow XML Schema spec closer



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:



        In package javax.xml.datatype, classes XMLGregorianCalendar and Duration
        were added to provide a Java representation for the XML Schema builtin
        datatypes xsd:dateTime and xsd:duration.

        The proposed approach introduced a class javax.xml.datatype.XMLGregorianCalendar
        that extended java.util.GregorianCalendar, attempting to address
        the mismatch in binding via overrides in the subclass.

        Central to a majority of the issues raised
        is that it is not appropriate to have XMLGregorianCalendar extend
        java.util.GregorianCalendar. There are too many differences between
        Java calendar representation, java.util.GregorianCalendar, and XML Schema
        definition of xsd:dateTime.


        1. XMLGregorianCalendar data representation for xsd:dateTime "year" and
           "fractionalSecond" field is insufficient.

           - The value space of xsd:dateTime "year" requires a Java representation of
             BigInteger. java.util.Calendar.YEAR field can only be accessed as int.

           - The value space of xsd:dateTime "fractionalSeconds" requires a Java
             representation of BigDecimal.
             java.util.Calendar.MILLISECOND only has precision for three fields.

        2. No way to determine partial-order relation between instances
           of XMLGregorianCalendar. (Same issue for Duration.)

           xsd:duration and xsd:dateTime are specified as partially
           ordered in XML Schema specification. Thus, a comparator that
           returns 4 values, not just the typical three that a totally
           ordered comparator returns. New method also would return
           a value denoting INDETERMINATE.

        3. XMLGregorianCalendar equals and hashcode methods be defined relative
           to the XML Schema comparison methods.

        4. Incompatibility between java.util.Calendar TimeZone and
           xsd:dateTime timezone offset.
           Major differences:
           - java.util.Calendar daylight savings timezones are not representable
             in XML Schema datatype xsd:dateTime.
           - java.util.Calendar default for timezone is current machines default.
             XML Schema xsd:dateTime has no default timezone, it is significant
             to remember that no time zone exists when specifying comparison
             (see issue 2 and 3).
             The existence of daylight savings timezone in an XMLGregorianCalendar
             implementation that extends java.util.Calendar would be undefined
             for both addition of duration and comparison as defined in XML
             Schema Part 2.

        5. Add method XMLGregorianCalendar.add(Duration) that is documented to
           work as specified in XML Schema Part 2.

        6. Parse/printing

        (a)Have only one parse method for all XML Schema builting datatypes
           representing date/time datatypes instead of one for each of
           8 datatypes. XML Schema lexical representation is unique for
           all 8 datatypes: dateTime, date, time, gYearMonth, gMonthDay,
           gYear, gMonth and gDay.

           from<XMLdatetime_datatypes>(String) ==> parse(String lexicalRep).

           This change eliminates a lot of API and simplifies handling of
           XML Schema union over XML Schema date/time datatypes.

        (b)Have only one print method for all XML Schema datatypes
           representing date/time datatypes.

           String to<XMLDatatime_datatypes() ==> String toXMLFormat()

        (c)introduce a method that allows one to determine which XML Schema builtin
           datatype an XMLGregorianCalendar instance represents at any point in time.
           Proposed method name is getXMLSchemaType().



            Issue Links



                jsuttorsunw Jeff Suttor (Inactive)
                jfialli Joe Fialli
                0 Vote for this issue
                0 Start watching this issue