If you are not dependent on having the custom date format in the xml, an
option is to use xs:date in the xml and your custom format internally by
providing your own parse/print methods. That way you can still get the
benefits of xs:date's stronger validation support.
I solved a similar problem by providing a custom print method when I needed to
get rid of the time zone information (2003-04-15+01:00).
Citerat fr?n Sriram Thyagarajan <Sriram_Thyagarajan_at_KEANE-NNE.com>:
> One thing I am not clear is, if Schema's default validation is always
> going
> to kick in, then won't this limit the customization described in Page 97
> of
> users guide particularly for xs:date types ?
>
> Overriding default bindings - "Override the specified default binding of
> XML
> Schema built-in datatypes to Java datatypes....."
>
> -----Original Message-----
> From: Sriram Thyagarajan
> Sent: Thursday, April 10, 2003 4:19 PM
> To: 'JAXB-INTEREST_at_java.sun.com'
> Subject: RE: Customaziation and validation
>
>
> Ok.. I got it... even though I define a method for parsing the value,
> it
> should still confirm to the date format of CCYY-MM-DD. I mis-understood
> it
> as a way of overriding the default validation i.e if I have a method
> customizing the conversion of xs:date to jxb:java.util.Calendar, I
> understood it as the method that would get executed whenever a xs:date
> field
> is encountered during unmarshalling and the default validation will not
> be
> executed ....
>
> So if a element is defined as xs:date it will always need to be in the
> format CCYY-MM-DD ? Is there a way to change this format ?
>
> Looks like the following happens... when a element defined as date and
> has
> the value 20030410
>
> 1. An even gets thrown, because it does not fall in the default format
> of
> CCYY-MM-DD
> 2. My customized method gets executed, which converts it into a
> java.util.Caledar object.
>
> My process aborts when there are ValidationEvents.. So even though the
> customized convertor, converted the value... because of the
> ValidationEvent,
> the process aborts...
>
> -----Original Message-----
> From: Kohsuke Kawaguchi [mailto:Kohsuke.Kawaguchi_at_Sun.COM]
> Sent: Thursday, April 10, 2003 3:42 PM
> To: JAXB-INTEREST_at_JAVA.SUN.COM
> Subject: Re: Customaziation and validation
>
>
> > Woudn't it be valid according to the Schema specs ? The schema
> defines
> an
> > element as type SimpleType and as the one which has different
> conversion
> > rules ?
>
> The conversion rules are defined by JAXB. So it's not something the XML
> Schema spec recognizes. And YYYYMMDD is NOT a valid xs:date value.
>
> It's this simple; your schema says the AccidentDate element will have
> the xs:date type. YYYYMMDD is not a valid xs:date value. Therefore
> <AccidentDate>20030410</AccidentDate> is not valid wrt your schema.
>
> Just try any XML schema processor out there. They should agree with
> this.
>
>
> > So does this mean that if I have validation turned on, then
> Conversion
> using
> > other methods cannot be done ?
>
> You can. It's just that the meaning of the validation is not affected
> by
> any of the JAXB customization. XML Schema validation is defined purely
> on the schema and the instance.
>
>
>
> > Just curious, one solution I can think in my situation is to catch
> that
> > event and discard it as if it did not happen...
>
> Would you elaborate what you think a problem is? Because I don't see
> any
> problem.
>
>
> regards,
> --
> Kohsuke KAWAGUCHI 408-276-7063 (x17063)
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
...................................................................
GRATIS LOKALNYHETER MED E-POST!
http://www.enytt.nu