Both modules are complete. Rather than appending them to e-mail, I've zipped the 2 modules plus a short XSchemaValidator.java diff file into ftp://ftp.peakin.com/pub/xerces/tv.zip
Hopefully we'll see more definition of these types in the near future. george ***************************** General Implementation Notes: Both validators store the parsed values for their facets so they are not re-parsed for each comparison. Both validators support minInclusive, maxInclusive, minExclusive, maxExclusive, and enumeration facets. Both validators cache their parsed results in a Hashtable. With real-life data, I'm not sure just how much of a benefit this will be. If you have lots of recurring values, it will help a lot. If not though, the performance penalty for a failed lookup is very minor. You can limit the size of the cache with the constant CACHE_LIMIT. If caching proves beneficial, the settings may be candidates for properties. TimeZone is assumed to be the local timezone (user.timezone) if not specified. ************************************* Implementation notes for TimeInstant: Although the 12/17 Schema WD doesn't specifically state it, Ashok Malhotra confirmed that right-truncated versions of timeInstant would be appropriate. Seconds beyond 3 decimal places can be specified but are ignored. Time zone offset can be specified in just hours (-07) or hours and minutes (-07:00) The year can have 5 digits if you feel the need to specify instants beyond year 9999. The year can be negative to designate 'BC' instead of 'AD'. java.util.Calendar support for 'BC' is a little shaky though. All these examples are valid: 2000-01-23T05:45 2000-01-23T05:45:30 2000-01-23T05:45:30.505 2000-01-23T05:45Z 2000-01-23T05:45:30Z 2000-01-23T05:45:30.505Z 2000-01-23T05:45+01:00 2000-01-23T05:45:30+01:00 2000-01-23T05:45:30.505+01:00 2000-01-23T05:45-07 2000-01-23T05:45:30-07 2000-01-23T05:45:30.505-07 -2000-01-23T05:45+01:00 12000-01-23T05:45:30+01:00 -12000-01-23T05:45:30.505+01:00 ************************************* Implementation Notes for TimeDuration: The following assumptions are made for durations expressed as PnYnMnDTnHnMnS: 1 year = 31104000 seconds 1 month = 2592000 seconds 1 day = 86400 seconds 1 hour = 3600 seconds 1 minute = 60 seconds I make no claims as to whether this is correct, or not. It just 'is' until something else is defined. Seconds beyond 3 decimal places can be specified but are ignored. Negative duration can be specified. The following are valid: P1Y1M1DT1H1M1.234999S = 1 year, 1 month, 1 day, 1 hour, 1 minute, 1.234 seconds PT72H = 72 hours P12MT72H = 12 months, 72 hours -P24M = -24 months -PT24M = -24 minutes P356D = 365 days - this is NOT = 1 year or 12 months. For periods expressed in ISO formats 'CCYY-MM-DDThh:mm:ss/PnYnMnDTnHnMnS' or 'PnYnMnDTnHnMnS/CCYY-MM-DDThh:mm:ss', a Calendar object is created for the fixed start or end, then 'rolled' up or down the incremental amount. You can also specify a duration with both fixed start and end points: 'CCYY-MM-DDThh:mm:ss/CCYY-MM-DDThh:mm:ss'. In this case, the duration is the millisecond difference between the 2 Calendar objects. Regardless of which format the duration is specified in, a duration is always positive if the end instant occurs after the start instant, and the duration is negative if the end instant occurs before the start instant. 2000-01-23T00:00/P1Y = 316224000 seconds (366 days, 2000 is a leap year) 2000-03-01T00:00/P1Y = 316360000 seconds (365 days, already after 2/29) P1Y/2000-01-23T00:00 = -316360000 seconds (-365 days, still before 2/29) P1Y/2000-03-01T00:00 = -316244000 seconds (-366 days, already after 2/29) Durations expressed solely in 'P' terms parse much faster than when pinned by a start or end instant. *************************************
