I'm glad to know that it is on the list. What I was suggesting was not an anticipatory change to the DOM interfaces (though supporting typed data in the DOM would be, of course, desired). But basically, allowing the DOM implementation internals to compact the data when it knew a specific base type (typically, real or integer, but possibly date).
As currently written, the NodeImpl class (in the C++) has a publically accessible DOMString member variable "value". There appears to be an accessor function for this (getValue), but not an obvious assignment function. Unless I want to hack DOMString, there is not a way for me to replace the DOMString value member with something that has string virtual functions, but actually holds the value as a integer or a double. Of course, there would be some transformation loss (0.0000000014 in the file might be returned as 1.4e-9 through the DOM). My naive view would be to: 1) Remove the public DOMString value attribute from NodeImpl 1a) Identify places that directly accessed NodeImpl.value and replace with appropriate NodeImpl virtual function. 2) Create a derived StringNodeImpl that has a private DOMString value attribute. 3) Create a derived DoubleNodeImpl and LongNodeImpl that has a private double or long value attributes. 4) Rework the NodeImpl factory so that the user and/or schema can determine the appropriate NodeImpl (default would be that everything would be a StringNodeImpl) 5) Benchmark to determine impact on performance. If someone knows a cleaner way to attack this problem, let me know. Otherwise, I'm willing to do some prototyping and report back performance and any issues that I encounter. Is anyone else interested in this? I think that all those changes would be beneficial now for access through DOM 1 and 2 and would be helpful for whatever DOM 3 becomes. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 1999 11:30 AM To: [EMAIL PROTECTED] Subject: Re: Your idea here > 2. Support for a type-aware DOM Speaking as a member of the DOM Working Group: We're aware of that issue. Now that the datatypes in the XML Schema design are starting to settle down, we might be able to do something about it. Validation/content-model support is one of the things we hope to (finally!) address in DOM Level 3. You might want to hold off prototyping it in Apache until there's some indication of what the DOM's final solution is going to look like. ______________________________________ Joe Kesselman / IBM Research
