My argument has already been that any industry which has to deal with such
things long since has come up with its own means of dealing with them and
its own nomenclature. So why bother putting stuff like this into Schema to
begin with? The medical industry isn't going to suddenly stop using its QXX
type nomenclature for periodic application of some drug or intervention.
They are just going to encode into their XML the same nomenclature they've
used forever and their own applications will interpret them appropriately.
I know that there are some benefits from standardization, such as
interchange. But, with different application level semantics being imposed,
this kind of data cannot be interchanged very reliably anyway.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"George T. Joseph" <[EMAIL PROTECTED]> on 01/19/2000 12:32:34 PM
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: RE: Proposal for Xerces-J Schema validators for timeInstant and
timeDuration
I agree that 30D isn't always equal to 1M, I just don't know what to do
about
it. I don't think there's going to be a way to make everyone happy with
timeDuration. If you specify a duration of 1M, do you mean 30D, or "this
date
next month", or "4 weeks from today"? If you specify 30D, is that less
than 1M
if you happen to be in January but greater than 1M if you're in February?
Should a start instant even be assumed at all?
What if you specify a duration of "2000-01-19T13:00:00/P1M"? Is that equal
to
"2000-02-01T13:00:00/P1M"? Should the start instants be disregarded during
comparson? Should you be using recurringInstant instead of timeDuration?
george
-----Original Message-----
From: Arnold, Curt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 19, 2000 11:13 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Proposal for Xerces-J Schema validators for timeInstant and
timeDuration
I had overlooked those sections. It definitely makes comparision precise.
I don't think it is acceptible for an application to not be able to
distinguish 30D from 1M since legally they are different things.
Hopefully,
you could parse out the months and years separately from the precise
durations and the do your range checks like
(this.months*259200+this.seconds) > (other.months*259200+other.seconds)
