RE: Schema, Part 2: Datatypes

> -----Original Message-----
> From:	Jeff Lowery [SMTP:jlowery@scenicsoft.com]
> Sent:	Friday, November 03, 2000 11:07 AM
> To:	'www-xml-schema-comments@w3.org'
> Subject:	Schema, Part 2: Datatypes
> 
> 1) I noticed a couple of definitions using the term 'positive negative
> infinity', which sounds like an oxymoron to me. Should it be 'positive and
> negative infinity'?
> 
Yes, thanx for catching that...it is now fixed in an internal WG draft.

> 2) Priority feedback on timeDuration:
> 
> Maybe I've been in the software industry too long, but I have trouble
> imagining any single task or set of tasks scheduled over more than a month
> having anything more than an approximate duration. So whether 1M = 30 days
> or 31 days or even 28 days may not matter for single tasks (composite or
> otherwise). Where it gets significant, however, is when you have sum of
> such
> tasks, or where you have a statistical mode of such tasks; then having an
> ordering for those durations could become critical for certain scheduling
> applications.
> 
What about:

	<inovice>
		<p>
			This invoice is due and payable in
			<due-date xsi:type='xsd:timeDuration'/>3M</due-date>
		</p>
	</invoice>

[true: most accounts payable are expressed in terms of DAYS, in order to get
around the inherent indeterminism of time durations]

> The only way I see to solve the ordering problems is to allow
> specification
> of the month through a qualifier:
> 
> 	1M(11)1D < 32D whereas 1M(12)1D = 32D; therefore 1M(11)1D <
> 1M(12)1D, where M(11) = November; M(12) = December
> 
> If the month is unqualified, then 30 days is assumed, so that:
> 
> 	1M1D < 32D
> 
> The tricky part is February, which is codependent on leap year; that means
> we need a year qualifier as well:
> 
> 	1Y(L)1M(2) > 1Y1M(2)
> 
> Here, if the Year is unqualified, it is assumed to be 365 days and
> therefore
> also M(2) = 28.
> 
> A bit messy, and I don't know if it conflict with the ISO 8601 spec, but I
> can't see a better way around the problem.
> 
Yes, a bit messy and not compliant with 8601 but certainly worth considering
in a future version of the spec.

pvb

Received on Friday, 3 November 2000 17:01:46 UTC