That is great news! I am also working on implementing Java XML Schema datatypes.

While I agree that these two datatypes should be normalized to a common unit of measure. The Dec, 17 draft says that in paragraph 3.2.7.1 about the S parameter. "The number of seconds can include decimal digits to arbitrary precision". The draft and ISO 8601 leaves quite open to what arbitrary precision means, so a timeduration could be normalized to seconds including an arbitrary precision fraction of a second.

Any input from somebody else in this group to what this should  be?

If you don't have cvs committing privileges I could help you committing your contribution to Xerces Java.

About the propose changes to the datatype validator API, validate, I think it could be put for votation.

I think that validation and data accessing should be separate. Being able to access the already normalized value is probably useful specially if you had to do that while validating.

A caveat is that instantiating a native Java datatype object is an expensive operation so for performance you may want to maybe use a Proxy to do the actual instantiation only when needed.


Jeffrey Rodriguez XML Java Development IBM Cupertino





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


______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com



Reply via email to