You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xerces.apache.org by "George T. Joseph" <gt...@peakin.com> on 2000/01/18 22:30:14 UTC

Proposal for Xerces-J Schema validators for timeInstant and timeDuration

I've been working on getting the Schema timeDuration and timeInstant datatypes for Xerces-J going over the weekend.  To do
enumeration and bounds checking, the attribute value and its constraints have to be normalized to a common unit of measure, say
milliseconds.  Once that's done and the value is determined to be valid, it would seem a shame to just throw that normalized value
away.  Many applications will have to normalize it again to make any use of it.

So, I'd like to propose a change to the datatype validator API.  Currently, the xValidator.validate() methods accept a String and
return void.  I'd like to see that changed to both accept and return an int that would be a StringPool index.  The StringPool object
itself would be passed via the constructors when they are invoked by XSchemaValidator.  The validate method could return either a
new index corresponding to the normalized value, or simply return the original value index.  The whole thing could be turned on or
off via a 'normalize-attribute-values' feature.

Comments anyone?  FYI: I've got timeDuration working pretty well and should have timeInstant in a day or so.  I'll post the diffs
using the current method signatures and leave the proposed change for possible later value added.

george


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

Posted by "George T. Joseph" <gt...@peakin.com>.
Yep, I did look at InternalDatatypeValidator but I think that DatatypeValidator
will still beed to be changed.  Since validate(int) is only in
InternalDatatypeValidator,  XSchemaValidator will need to test "v" in order to
decide if it should invoke v.validate(int) or v.validate(String) and whether it
should assign the result or not.  That's easy enough to do so if preserving the
distinction between the 2 interfaces makes more sense, it's not a problem.

george
-----Original Message-----
From: Ted Leung [mailto:twleung@sauria.com]
Sent: Wednesday, January 19, 2000 2:02 PM
To: xerces-dev@xml.apache.org
Subject: Re: Proposal for Xerces-J Schema validators for timeInstant and
timeDuration


George,

Did you look at the InternalDatatypeValidator interface -- this is probably
a little closer to what you
want but still doesn't have a return value.  The original intent was that
DatatypeValidator be an API
for anyone who might want datatype validation services, and that
InternalDatatypeValidator be more
aware of Xerces internals.

Ted

----- Original Message -----
From: "George T. Joseph" <gt...@peakin.com>
To: "xerces-dev" <xe...@xml.apache.org>
Sent: Tuesday, January 18, 2000 1:30 PM
Subject: Proposal for Xerces-J Schema validators for timeInstant and
timeDuration


> I've been working on getting the Schema timeDuration and timeInstant
datatypes for Xerces-J going over the weekend.  To do
> enumeration and bounds checking, the attribute value and its constraints
have to be normalized to a common unit of measure, say
> milliseconds.  Once that's done and the value is determined to be valid,
it would seem a shame to just throw that normalized value
> away.  Many applications will have to normalize it again to make any use
of it.
>
> So, I'd like to propose a change to the datatype validator API.
Currently, the xValidator.validate() methods accept a String and
> return void.  I'd like to see that changed to both accept and return an
int that would be a StringPool index.  The StringPool object
> itself would be passed via the constructors when they are invoked by
XSchemaValidator.  The validate method could return either a
> new index corresponding to the normalized value, or simply return the
original value index.  The whole thing could be turned on or
> off via a 'normalize-attribute-values' feature.
>
> Comments anyone?  FYI: I've got timeDuration working pretty well and
should have timeInstant in a day or so.  I'll post the diffs
> using the current method signatures and leave the proposed change for
possible later value added.
>
> george
>
>



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

Posted by Ted Leung <tw...@sauria.com>.
George,

Did you look at the InternalDatatypeValidator interface -- this is probably
a little closer to what you
want but still doesn't have a return value.  The original intent was that
DatatypeValidator be an API
for anyone who might want datatype validation services, and that
InternalDatatypeValidator be more
aware of Xerces internals.

Ted

----- Original Message -----
From: "George T. Joseph" <gt...@peakin.com>
To: "xerces-dev" <xe...@xml.apache.org>
Sent: Tuesday, January 18, 2000 1:30 PM
Subject: Proposal for Xerces-J Schema validators for timeInstant and
timeDuration


> I've been working on getting the Schema timeDuration and timeInstant
datatypes for Xerces-J going over the weekend.  To do
> enumeration and bounds checking, the attribute value and its constraints
have to be normalized to a common unit of measure, say
> milliseconds.  Once that's done and the value is determined to be valid,
it would seem a shame to just throw that normalized value
> away.  Many applications will have to normalize it again to make any use
of it.
>
> So, I'd like to propose a change to the datatype validator API.
Currently, the xValidator.validate() methods accept a String and
> return void.  I'd like to see that changed to both accept and return an
int that would be a StringPool index.  The StringPool object
> itself would be passed via the constructors when they are invoked by
XSchemaValidator.  The validate method could return either a
> new index corresponding to the normalized value, or simply return the
original value index.  The whole thing could be turned on or
> off via a 'normalize-attribute-values' feature.
>
> Comments anyone?  FYI: I've got timeDuration working pretty well and
should have timeInstant in a day or so.  I'll post the diffs
> using the current method signatures and leave the proposed change for
possible later value added.
>
> george
>
>