Problem in deriving class from System.Xml.XmlNode

[Mahesh Devjibhai Dhola]

Hi All,
I want to make a custom class in c#, which extends System.Xml.XmlNode class
of BCL.

Now in custom class, I have implement abstract methods of XmlNode class
also. Now when I am trying to run the class it gives an error that
"System.Xml.XmlNode.XmlNode() is inaccessible due to its protection level".

This error comes because XmlNode has not any public constructor. I found
XmlNode has two constructor but both are private or friend (i dont know
exactly).

I also found one MSDN article where it says that "Never derive any class
directly from XmlNode" but its just recommendation.
(http://msdn.microsoft.com/library/de...-us/cpguide/ht
ml/cpconextendingdom.asp)

Though, Microsoft has derived some of BCL classes from base XmlNode, so why
we can not derive?
System.Object
System.Xml.XmlNode
System.Xml.XmlAttribute
System.Xml.XmlDocument
System.Xml.XmlDocumentFragment
System.Xml.XmlEntity
System.Xml.XmlLinkedNode
System.Xml.XmlNotation

So i think there must be some way out of this....

So what to do to create a derived class from XmlNode?
I heard that many experts are giving their service in news groups. So please
help me out of this.

I have already derived few of my classes from XmlDocument, XmlElement,
XmlAttribute etc. So i dont want to derive from them but i want to derive
the class from XmlNode it self. Please help me to get the answer...

Thanks in Advance.

Thanking you,
Mahesh Devjibhai Dhola
"Empower yourself...."

[Derek Harmon]

"Mahesh Devjibhai Dhola" <md*****@hotmail.com> wrote in message news:%2****************@tk2msftngp13.phx.gbl...

I want to make a custom class in c#, which extends System.Xml.XmlNode class
of BCL.
What are you trying to accomplish by extending the XmlNode class?
This error comes because XmlNode has not any public constructor.
Nor a protected constructor. Kind of suggests it can't be done, huh?
I also found one MSDN article where it says that "Never derive any class
directly from XmlNode" but its just recommendation.
Like one anonymous Physics professor said of the "speed-of-light," it's not just
a good idea -- it's the Law. Here's why ...

When you subclass XmlNode, you need to override the factory method on
XmlDocument that creates instances of your XmlNode, right? If you look
at the man page for that method,

http://msdn.microsoft.com/library/en...NodeTopic1.asp

You'll see that of the three overloads, two take the XmlNodeType enumeration
which you have no way of adding your own custom node type to. The one over-
load remaining takes a string name, but as the above topic says, it will throw an
ArgumentException if that string name doesn't correspond to one of the known
W3C DOM-inspired node types.

I've chosen this man page in particular, because it includes a cross-reference
chart illustrating which node types are permitted to be placed into other node
types. Notice that there is no place on this chart for an XmlNode subclass,
so even if you could create one, you wouldn't be able to add it into an Xml-
Document.

Additionally, if you look at the XmlNode's Clone( ) method,

http://msdn.microsoft.com/library/en...CloneTopic.asp

It indicates that nodes other than a selection of XmlNodeTypes listed in that
topic, cannot be cloned, which places a limitation on an XmlNode subclass
that doesn't exist for any of the W3C DOM node types at all. It means, for
instance, that the ImportNode( ) method of XmlDocument can't work for
your custom XmlNode subclass because importation sometimes requires
the deep cloning of an XmlNode's children (if it has any).

Additionally, a lot of the features of XmlDocument, in accordance with the
W3C DOM specification, work off of switching based on the XmlNodeType
(for instance, the afforementioned chart of what node types are allowed inside
of other node types).

There's no way for the implementation to know what your custom XmlNode
subclass is supposed to do. I believe the class designers behind the BCL have
done us a proper service by deciding to conceal XmlNode's constructor and
prevent it from being directly subclassed in the way that they have.

Were this not the case, developers might subclass XmlNode directly and be left
to wonder why XmlDocument suddenly misbehaves. In the presence of arbitrary
and unknowable XmlNode subclasses, it's easy for the node type checking logic
to run afoul. Custom nodes are incongruent with the known node types, and thus
should not be allowed.
Now in custom class, I have implement abstract methods of XmlNode class
also.

What did you do when you overrode the abstract NodeType property?

http://msdn.microsoft.com/library/en...eTypeTopic.asp

If you returned an XmlNodeType that's associated with one of the other concrete
XmlNode subclasses (XmlComment, XmlElement, etc.), then you should instead
extend from that subclass -- and not XmlNode.

It really comes down to what you're trying to accomplish, and which W3C
DOM node type your content truly is (since XmlNode is purposefully abstract,
it's not a legitimate choice), that indicates the appropriate class you should
subclass here.
Derek Harmon

[Mahesh Devjibhai Dhola]

Dear Derek,
Thanking you very much on you guidance.
It clears my point.
Thanks again,
But can you tell me? Why microsoft has desinged these classes such like
these? Why they are not giving us rights to extend the classes?
What are design aspects from their view?
What is your thinking on this?
Mahesh Devjibhai Dhola
"Empower yourself...."

"Derek Harmon" <lo*******@msn.com> wrote in message
news:Oa**************@TK2MSFTNGP09.phx.gbl...

"Mahesh Devjibhai Dhola" <md*****@hotmail.com> wrote in message news:%2****************@tk2msftngp13.phx.gbl...

I want to make a custom class in c#, which extends System.Xml.XmlNode class of BCL.

What are you trying to accomplish by extending the XmlNode class?

This error comes because XmlNode has not any public constructor.

Nor a protected constructor. Kind of suggests it can't be done, huh?

I also found one MSDN article where it says that "Never derive any class
directly from XmlNode" but its just recommendation.

Like one anonymous Physics professor said of the "speed-of-light," it's

not just a good idea -- it's the Law. Here's why ...

When you subclass XmlNode, you need to override the factory method on
XmlDocument that creates instances of your XmlNode, right? If you look
at the man page for that method,

http://msdn.microsoft.com/library/en...NodeTopic1.asp
You'll see that of the three overloads, two take the XmlNodeType enumeration which you have no way of adding your own custom node type to. The one over- load remaining takes a string name, but as the above topic says, it will throw an ArgumentException if that string name doesn't correspond to one of the known W3C DOM-inspired node types.

I've chosen this man page in particular, because it includes a cross-reference chart illustrating which node types are permitted to be placed into other node types. Notice that there is no place on this chart for an XmlNode subclass, so even if you could create one, you wouldn't be able to add it into an Xml- Document.

Additionally, if you look at the XmlNode's Clone( ) method,

http://msdn.microsoft.com/library/en...CloneTopic.asp
It indicates that nodes other than a selection of XmlNodeTypes listed in that topic, cannot be cloned, which places a limitation on an XmlNode subclass
that doesn't exist for any of the W3C DOM node types at all. It means, for instance, that the ImportNode( ) method of XmlDocument can't work for
your custom XmlNode subclass because importation sometimes requires
the deep cloning of an XmlNode's children (if it has any).

Additionally, a lot of the features of XmlDocument, in accordance with the
W3C DOM specification, work off of switching based on the XmlNodeType
(for instance, the afforementioned chart of what node types are allowed inside of other node types).

There's no way for the implementation to know what your custom XmlNode
subclass is supposed to do. I believe the class designers behind the BCL have done us a proper service by deciding to conceal XmlNode's constructor and
prevent it from being directly subclassed in the way that they have.

Were this not the case, developers might subclass XmlNode directly and be left to wonder why XmlDocument suddenly misbehaves. In the presence of arbitrary and unknowable XmlNode subclasses, it's easy for the node type checking logic to run afoul. Custom nodes are incongruent with the known node types, and thus should not be allowed.

Now in custom class, I have implement abstract methods of XmlNode class
also.
What did you do when you overrode the abstract NodeType property?

http://msdn.microsoft.com/library/en...eTypeTopic.asp
If you returned an XmlNodeType that's associated with one of the other concrete XmlNode subclasses (XmlComment, XmlElement, etc.), then you should instead
extend from that subclass -- and not XmlNode.

It really comes down to what you're trying to accomplish, and which W3C
DOM node type your content truly is (since XmlNode is purposefully abstract, it's not a legitimate choice), that indicates the appropriate class you should subclass here.
Derek Harmon

[Derek Harmon]

"Mahesh Devjibhai Dhola" <md*****@hotmail.com> wrote in message news:u6**************@TK2MSFTNGP10.phx.gbl...

But can you tell me? Why microsoft has desinged these classes
such like these? Why they are not giving us rights to extend the
classes?
I'll summarize the points made below on my opinion of
why XmlNode shouldn't be subclassed:

* In the DOM model as defined by the W3C (not Microsoft),
XmlNode is an abstraction.

* The DOM model has express rules about where elements,
attributes, text nodes, comments, processing instructions,
CDATA sections, etc., can appear. These are concrete
objects.

+ If you subclass an XmlElement, you have an element, and
it can be placed within a document where elements are allowed
to be placed by the W3C DOM recommendation.

+ If you subclass an XmlNode, you don't really have anything
tangible. It can't go anywhere within a document, because it
isn't allowed to exist within the document.

* .NET uses an enum, XmlNodeType, to list what these
concrete types are, and does switching logic based on
these enum values to ensure the integrity of the XML
DOM document. New values can't be added to these
enums, and custom logic can't be integrated into this
switching logic.
What are design aspects from their view?
What is your thinking on this?

I believe the class design -- and justifiably so -- doesn't
let developers hurt themselves by subclassing XmlNode
directly. There's no reason to directly subclass XmlNode,
instead of subclassing one of it's concrete subclasses
such as XmlElement, XmlProcessingInstruction, etc.

If you look at how other XML offerings have impl'd the
DOM, like Apache Xerces-J, you'll see several of the
same restrictions are in place to protect developers.

In Xerces-J, Node is an interface and it exposes a
getNodeType( ) function that must return one of the
static final constants defined on the Node interface.
These correspond to .NET's XmlNodeType enum.

Although a Xerces-J application may have classes
that implement Node, they always must define get-
NodeType( ) to return one of those constants (none
of which are "Node").

A Node's appendChild( ), insertBefore( ), etc., methods
are defined to throw a DOMException with an error of
HIERARCHY_REQUEST_ERR when an attempt is
made to add/insert a node whose getNodeType( )
is not supported within the given node (i.e., no
Elements are allowed to be added as children to
an Attr).

The real question you need to answer for yourself
is what you're trying to achieve by subclassing
XmlNode directly? Where do you think it belongs
in an XmlDocument? What are it's characteristics?

When you've answered these questions about the
content model you want for this node, what you'll
see is one of XmlNode existing subclasses already
has these characteristics, this proper place in the
structure of the XmlDocument. Extend that class
to add the additional features you want to affect.
Derek Harmon