Re: Identity versus Equality in enumerations and fixed value constraints

Dave Peterson writes:
> One question:  If you don't care about precision, why are you using
> precisionDecimal?  I'm not surprised that if you use the wrong datatype
> you won't get the results you want.  This just sounds like a good argument
> for not losing (aPrecision) decimal.
> 
> Why do you expect to be able to specify a "fixed" attribute and then
> be able to give it different values?

Not everyone is a numerical analyst. "Oooh look, here's a datatype to use for
numbers with decimal points: I'll use it." much later.... "Oops, I need to put
a constraint on the values of that element" much much later... "My software
emits two digits after the decimal point for numeric values and it won't
validate against your schema"

Or, a more plausible scenario, perhaps: organization B uses public schema from
organization A and wants to add fixed value constraints to certain values that
came from that public schema. If the public schema defined those values a
precision decimals, organization B loses.

> Your use case is certainly possible.  The use case where one *does* care
> about allowing only a particular value, without allowing all other
> equal-but-not-identical values, is certainly also possible, and just
> as valid.  Whichever one is chosen as "the way to go", the other will
> have to use subtype logic.

Yes, certainly. If we don't lose precisionless-decimal, the answer would be: use
that, not precisionDecimal, although that won't help folks who are trying to
add their own value constraints to a public schema over which they had no
control. I guess I would then say that our best practices recommendation for
public schemas would be to avoid precisionDecimal. Still, last I checked, we
seemed to be inclined to drop precisionless-decimal on the theory that no one
would be harmed in practice and having two decimal types would be confusing.

//Mary

Received on Friday, 3 December 2004 18:33:12 UTC