RE: [xml] xmlreader interface

["Stéphane Bidoul" <stephane bidoul softwareag com>]

>   No, the only point is that APIs are not cast in stone, for
> example I may swicth back the Python wrapper generator to 
> generate an uppercase for the first letter for consistency
> with the C# spec and documentation.

Why not... OTOH, changing case to match language traditions
does not hurt, IMHO.
 
> > a small one in moveToNextAttribute(): once the last
> > attribute is reached, the reader always return
> > properties of the last attribute (resetting
> > reader->curnode to NULL before return 0 seems 
> > to works for me).
>
>   From what I understood of the interfaces, that's the
> normal behaviour, and the MoveToElement method is the
> right way to go back to the top node. If you have a C#
> MS implementation around that could be a good idea to check.
> http://dotgnu.org/pnetlib-doc/System/Xml/XmlTextReader.html#Xm
lTextReader.MoveToElement%20Method

I checked in C#: you're interpretation is correct.
I misunderstood the problem, my fix is wrong, 
but there is a problem (on my machine, at least ;-)).
The doc says that MoveToNextAttribute() must stay on the last
attribute when it has been reached, and MoveToElement() can be used
switch back to the Element node. However, the next Read() should
move to the next node in the stream (attributes being on a kind of
"different stream", right?).

Here's a python test.

import StringIO
import libxml2

f = StringIO.StringIO("""<a><b b1="b1"/><c>content of c</c></a>""")
input = libxml2.inputBuffer(f)
reader = input.newTextReader("test1")

while reader.read():
    print "%s (%s) [%s]" % (reader.nodeType(),reader.name(),reader.value())
    if reader.nodeType() == 1: # Element
        while reader.moveToNextAttribute():
            print "-- %s (%s) [%s]" % (reader.nodeType(),reader.name(),reader.value())

It prints:

1 (a) [None]
1 (b) [None]
-- 2 (b1) [b1]
2 (x?{) [¿?{]
2 (x?{) [¿?{]
2 (x?{) [¿?{]
2 (x?{) [¿?{]

where I expect:

1 (a) [None]
1 (b) [None]
-- 2 (b1) [b1]
1 (c) [None]
3 (#text) [content of c]
15 (c) [None]
15 (a) [None]

Note that the node count is the same.
A similar program in MS C# gives similar results.
So I guess that Read() should do something a little
bit different if the current node is an attribute?

> > Then I've a small question: do you plan
> > to support entity resolution through that API?
> > (I've seen the ResolveEntity in the spec,
> > is there another mechanism that could do it?)

>  Well the normal XmlTextReader API doesn't allow entity
> resolution, but there is no reason I can't add it. Basically
> if you add the extra parser flags to load the DTD then
> that should be relatively easy.

I would love that...

XmlTextReader cannot resolve entities indeed.
In MS .NET it's the XmlValidatingReader that can.
That one has an "EntityHandling" property that controls
entity resolution behaviour (as I understand it, the default is
to resolve transparently without exposing EntityReference nodes,
then there is a mode where EntityReference nodes are exposed and
the client must call ResolveEntity on such nodes to parse the entities).

-sbi