Re: [DotGNU]System.Xml

[minddog]

On Sunday 12 January 2003 12:11, Gopal V wrote:
> If memory serves me right, Simon Guindon wrote:
> > Anyways, we have the chicken and the egg problem here.
> > XmlDocument.LoadXml uses XmlTextReader to load structure into
> > XmlDocument. Problem here is, should LoadXml do the Appending of children
> > and attributes,

We have to start where the egg is created from itself, XmlTextReader...

> I had an idea on how to solve this issue with a hack (ugly hack) ... here
> is that hack... I dunno if this is the right way to do it , but this sure
> is one way to avoid building a DOM ... and yet store the set of attributes
> for that single node in the XmlTextReader ...


> This will mean that MoveToAttribute() will not require seekable readers ,
> if it needs to go back ...
>
> The hack bypasses the XmlDocument.Create functions to allow people to just
> build things ... But handle with care , the stuff should never leave the
> XmlTextReader or the entire effort bombs ...
>
> This might break future development ... because I don't know what we're
> going to do next ... So with a large grain of salt, this is a new idea :).

Interesting, i've taken a liking to your fix, but hacks like this put in place 
for an XmlReader just don't seem necessary unless the design is flawed to 
begin with.  I propose we remove all DOM type stuff and use XmlTextReader as 
just a a smart Xml character iterator.  We could create a table that holds 
values of key places and continually caching all char data till the user 
chooses to Flush() the data.  That way MoveToWhatever can just say bring me 
to 'node5' and reads from the table the value and the cached data from that 
point beyond is transferred to the buffer.  

Just an idea, so we don't have to keep creating hacks to get around problems 
creating document objects in the reader.


Regards,
-- 
--minddog( Adam Ballai )

"I try to take it one day at a time, but several of them attack me at once."
-mistyflip