RE: Proposal for Xerces-J Schema validators for timeInstant and t imeDuration

["Arnold, Curt" <Cu...@hyprotech.com>]

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. 

RE: Proposal for Xerces-J Schema validators for timeInstant and timeDuration

["George T. Joseph" <gt...@peakin.com>]

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:Curt.Arnold@hyprotech.com]
Sent: Tuesday, January 18, 2000 6:25 PM
To: 'xerces-dev@xml.apache.org'
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.