"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om...
Why not just create a new XML document, try to load into that, and if
that fails return the old one? Why try to load it into the original at
all?
My observation is that it's not obvious that XmlNode's Clone( )
method is virtual, returning a polymorphic XmlNode, and that
XmlDocument IS-A XmlNode. If a programmer knows all three
facts and makes a connection between them to the problem,
then an effective solution is obvious.
On the other hand, many developers new to a class design and
driven by necessity will fallback into looking for a way to thunk
from XmlNode into the XmlDocument. The path many choose
(as being more obvious) is OuterXml.
In this specific respect, the XML DOM recommended by the
W3C is less intuitive compared to a model in which polymorphic
types are "in the developer's face." OOP languages make these
principles sublime in their subtlety, and less visible to the untrained
eye. Tools then must pick up the slack, but what tools can fit into
the developers workflow with continuity as they solve this problem?
The .NET Framework SDK documentation does well by listing
inherited members in subclass docs, and that helps (imagine
how unwieldy the docs for XmlValidatingReader or PropertyGrid
would be if the SDK didn't document inherited members).
Today, its an issue of developers having to gain experience with
the XML DOM object model, whereupon making the connections
I cite above comeabout naturally with time.
Although the learning curve will solve this for everybody in time,
it's still a good case for motivating the evolution of the object model,
language and tools as they enable more productive developers in
the future (that in turn drive greater ROI for the tasks given them
by their managers, who in turn have larger budgets with which to
purchase new tools).
Derek Harmon