Fabio, Thanks for your reply. > > 1. Annotation > > ... > > How can we expose *information items*, in what form? > > Isn't Xerces capable of generating XNI/SAX events from a DOM?
Is it? :-) Are you suggesting that we store DOM sub-trees in XSAnnotation, and SAX users generate SAX events from the DOM trees? We want to avoid explicit dependency on DOM, otherwise a SAX-only parser wouldn't be able to implement the API. > > 3. Actual values > > > > How to expose actual values? Do we want to define interfaces to > > represent > > the actual values (date/time types especially)? After we have such > > interfaces, we can return "Object" from related methods. > > I think that date and time objects need to be wrapped to associate > appropriate methods to all the different variants (i.e. date vs > duration, etc.). 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.). > The others can probably do with a simple Object representation > containing the actual value, this would slightly complicate things for > comparison but would keep memory occupancy to acceptable levels (adding > a wrapper would imply adding quite a bit of overhead to the memory > footprint). Right. This is what I had in my mind. > 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. 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"). 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. BTW, we currently represent hexBin and base64Bin values as String's. But I think it should be "byte[]". Right? For now, I won't include actual values in the interface (because I believe more discussion is necessary), and only expose lexical values. After I implemented these interfaces, I'll come back and add the actual value support. Thanks, Sandy Gao Software Developer, IBM Canada (1-905) 413-3255 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
