On Friday, May 10, 2002, at 09:02 AM, [EMAIL PROTECTED] wrote: > We could use one class for all data/time types. It can have a bunch of > getter methods to get different portions of the value (year, month, day, > etc.) and one method to get the type of the value (date, gYear, duration, > etc.).
I'd rather use a different class for each type, duration has specific methods for addition, comparison, etc that could be useful for applications. toString methods are different too. Ideally all the behavior implemented by the DV classes should be moved in the types themselves and the DVs should only delegate to the types. BTW: some basic types like xs:int are very common in schemas, why don't we do a special mapping for the Decimals that happen to be within the Int range and the Long range and return a more specific object? I think this would be a valuable optimization for many applications. >> Another solution could be to have an XSObject, XSBoolean, XSDecimal, >> etc. kind of hierarchy where equality and ordered can be defined >> appropriately in the base XSObject (vs relying on Object), without >> incurring in too much additional wrapper overhead. This route could also >> provide a simple way of obtaining the normalized value from the XSObject >> and keeping the original lexical representation separately. > > 1. It's a bit too complicated: we have to redo the work Java did, and > people have to learn how to use them. this is actually only true for Decimal, Boolean and String. Decimal and String could be wrapped without too much inefficiency... > 2. I'm not sure whether value1.equals(value2) works. At least one place in > the Schema spec (3.11.1) indicates that two values could be equal only > when > their types have derivation relation. That is, if you derive two types > from > "integer", the values of the two types aren't equal (even if they are both > "1"). mmm. One should also take into account the XQuery and XPath specs, there schema types are converted into a simplified type system where direct comparisons and operations are valid. I'm biased because I'm an XQuery implementor, but I'd say that these languages are the best client for the actual value representation and they should be able to reuse the schema types as efficiently as possible... > 3. I don't think we need to expose initial/original (lexical) value or > normalized (lexical) value from actual value. People would only be > interested in the "value" itself, or a canonical representation of it. ok, I was actually thinking of the canonical representation. My point is: should we favor the binary (most efficient) representation and only derive the text representation on demand from it? This supposes that the user is mostly interested to the binary value when he/she manipulates data and only uses the string for printing. > BTW, we currently represent hexBin and base64Bin values as String's. But > I > think it should be "byte[]". Right? right Thanks, cheers, - Fabio --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
