[Mono-list] Re: some System.XML bugfixes

[ginga(A.E.)]

Hello.

This is my error that I simply missed 'CreateNavigator(XmlNode).'
I think ville, Tim and Rafael are right, and please forget my previous
argument about 'non-inherited classes' problem. Sorry to disturb.

As to the report from ville ([Mono-list] XmlDocument.cs),
XmlDataDocument.cs (line 277) will become OK when changed from
'protected internal override' to 'protected override.'

Then you'll not be able to call CreateNavigator(XmlNode) in other
classes of System.Data.dll. But you can write like this:
  internal XPathNavigator CreateNavigatorInternal(XmlNode n)
  {
    // write what you want to do.
  }
  protected override XPathNavigator CreateNavigatorInternal(XmlNode n)
  {
    return CreateNavigatorInternal(n);
  }

If no other problems remain, then I'll fix up my mistake.
(I don't think bug 34797 is either mcs bug or C# spec bug.)

Attached to bottom is the message Tim (unexpected to) sent to me.
Tim says that it's ok to forward. (Thanks.)

# I don't think MS spec is doctrine. So I went into ECMA spec.

Thanks,

-- A.Enomoto

> > Hello.
> > 
> > > This is especially true since XmlDocument and XmlDataDocument are
> > > in different assemblies.  Unless, maybe the second CreateNavigator
> > > should be virtual instead of override.  Since CreateNavigator is
> > > protected internal in XmlDocument, would it be true that XmlDataDocument
> > > shouldn't even see that definition?
> > 
> > First of all, in relate to the specification, I missed that
> > XmlDataDocument don't have the declaration of CreateNavigator.
> > 
> > I would tend to agree with you. But 'public' and 'internal protected'
> > are importantly different when third parties (users) wanted to
> > call such methods from non-inherited classes.
> > 'public' methods can be called, but 'internal protected' methods can't. 
> > 
> > So I think 'public virtual' is better than 'internal protected.'
> 
> Well, that all depends on whether you actually want users to be able
> to call the method, right?  What do you mean by "better"?  In terms
> of Mono, to me, "better" means "closer to the Microsoft .NET implementation",
> not what feels better.  Sometimes the two are the same, but not always.
>  
> > BTW, MS document says that XmlNode.CreateNavigator() is 'public':
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/f
> > rlrfsystemxmlxmlnodeclasscreatenavigatortopic.asp
> > (With VB.NET syntax, it is explicitly declared as 'NotOverridable')
> 
> Yes, that's a different CreateNavigator.  Note that the one in XmlNode
> has no arguments.  The one defined as protected internal in XmlDocument
> and as protected in XmlDataDocument has an XmlNode argument.
> 
> > And I couldn't find the ECMA specification's definition for XmlDocument
> > class. Please tell me where that API specification is...
> > http://www.ecma.ch/ecma1/STAND/ecma-335.htm
> > ftp://ftp.ecma.ch/ecma-st/Ecma-335-xml.zip
> > 
> > I can't find why this method is not virtual. If MS developers
> > didn't have to override it, they might leave it 'public.'
> > But on the other hand, 'InsertAfter' is overridable, and then
> > 'CreateNavigator' should be 'public virtual' too.
> > Or if they have rational reason they don't want to override it, then
> > it should be 'public.'
> 
> I think you may be a bit confused here.  The XmlNode definition
> of CreateNavigator has a different signature than the one we
> are talking about which is overridden in XmlDataDocument.
> 
> I'm not aware of where the ECMA specification is.  The XmlDocument
> is described in the .NET Framework SDK documentation.
> 
> > Anyway, some bugfixes are required.
> > Thanks.
> 
> Yes, but what they are is unclear at present.  If we could implement
> it the same as the .NET specification, that would be ideal, but it seems
> that that spec is incorrect, since implementing it that way would cause
> the compiler to fail.  Someone needs to somehow identify the correct
> protection levels.  I would think, as I said, that the correct situation
> is to have the XmlDocument definition protected instead of protected
> internal, but I don't know for certain.
> 
> Cheers,
> 
> -- 
> Tim Coleman <tim@timcoleman.com>                       [43.43 N 80.45 W]
> BMath, Honours Combinatorics and Optimization, University of Waterloo
> Software Developer, Global Services, Open Text Corporation
> "Under capitalism, man exploits man.  Under communism, it's just the
>  opposite." -- J.K. Galbraith