RE: [xml] xmlreader interface

  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.

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")

    print "%s (%s) [%s]" % (reader.nodeType(),,reader.value())
    if reader.nodeType() == 1: # Element
        while reader.moveToNextAttribute():
            print "-- %s (%s) [%s]" % (reader.nodeType(),,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).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]