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.
