Re: SimpleTypes derived by restriction

My personal preference would be that "looser" facets would be tolerated,
though an ideal schema profiler might tell that you are wasting cycles or
optimize the evaluation.  I don't think that suboptimality is a good reason
to reject a document and the complexity involved in determining the active
constraint set is not justified in my opinion.  While figuring out the
looser constraint is fairly obvious for min/max, what if were trying to
better if one pattern is looser than another (and both could be active).

As a pattern, I know of no programming language that would fail to compile a
conditional like:

if(a > 1 && a > 2 && a < 5 && a <10) {}

It would be a conceptual error for the duration facet to be specified with
two distinct values in a type hierarcy.  You shouldn't be able to derive
from day and stretch the day to 25 hours.  The resulting type (25 hour
periods starting at a particular midnight) doesn't fit into the value space
of 24 hour periods starting at midnight.  I could see making a duplicate
specification of duration in a hierarchy an error, I would not try to
determine if the values of the duration were identical (say if one had said
P1D and another PT3600s)

Multiple period facets can make sense in a hierarchy make sense.  You could
create a derived type from time with a period of 48 hours that represented a
particular time of day every other day.  I can't see anything a schema
validation can do with the period facet.  It seems like a piece of
information only the application uses (if it wants) to determine the meaning
of the type.

Received on Wednesday, 26 April 2000 08:43:54 UTC