I'm not advocating a type-aware String pool, but a lexical comparison of 2 time duration or 2 time instant strings isn't worth a whole lot either. For my own application purposes, I need to insure that "PT121.123S" = "PT2M1.123S". If normalization is required anyway and it doesn't compromise performance, passing the normalized value back would seem to be a good deal (especially if you can turn it off). Ultimately, a type-aware DOM would be great.
There are certainly date/time issues remaining in the Schema WD and my code isn't going to fix them. All I can offer is an implementation that's as fast as I can make it, and produces predicatble results. The "best" normalization units of measure for a Java implementation seem to be "double" seconds for timeDuration, and "long" milliseconds for timeInstant. Also, for timeDuration purposes, I'm interpreting ISO8601 to mean that 1 year = 12 months and 1 month = 30 days (via para 3.12 and 3.18). That might not always be accurate but it is always precise. george -----Original Message----- From: Arnold, Curt [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 18, 2000 6:25 PM To: '[EMAIL PROTECTED]' Subject: RE: Proposal for Xerces-J Schema validators for timeInstant and timeDuration You definitely do not want to normalize the bound expressed in the schema on every validation. However, that should only require that the objects used for the min and max bounds contain the normalized object. Also, you want to normalize the string value once during the processing of the facets. However, longer term caching would appear to be the job of a type-aware DOM layer and not the validator. So I'd -1 a type-aware String pool. To anticipate the type-aware DOM, you might pass an optional DOMNode object to the validate method. The DOMNode object might eventually type specific setValue's [such as setValue(DOMTimeDuration)] methods for example that the validator could use to set the converted value. On timeDuration, If a timeDuration contains a year or month term, it can't be precisely converted to a quantify of seconds (or milliseconds). It could be converted to an integer number of months and seconds. Comparisions become tricky when there are both precise (W,D,H,S) terms and imprecise (Y,M) terms and I think that the Datatypes group really need to spell out how to handle it. Also, the spec seems to leave the ultimate precision of the timeDuration unspecified, so truncation at millseconds may be insufficient. I had suggested that the S term allow the full floating point lexical so that you could use time duration for very short and very long intervals. That usage would require a double to be used for the seconds. I'd again like to plug my HTMLHelp file for XML Schema (http://www.software.aeat.com/xml/resources.htm). It has a fairly substantial discussion on date and time types. If you'd like it as a zipped HTML files, I can send it to you that way.
