Re: [xml] xmlreader interface
- From: Daniel Veillard <veillard redhat com>
- To: Stéphane Bidoul <stephane bidoul softwareag com>
- Cc: xml gnome org
- Subject: Re: [xml] xmlreader interface
- Date: Sat, 28 Dec 2002 18:11:20 -0500
On Sat, Dec 28, 2002 at 11:36:02PM +0100, Stéphane Bidoul wrote:
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.
Well, being able to point directly at the C# doc is important.
I just mad that change in the generator and examples.
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.
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?
Okay I will look at it and fix it,
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...
Commited in CVS, there is a parser mode where you can enable
entities substitution. Check reader3.py when it shows up in CVS.
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).
yep, I still need to emulate the ResolveEntity() behaviour. should not
be too difficult. The XmlValidatingReader and XmlReader classes may be
provided easilly based on the existing stuff, it's mostly a refactoring
problem and at the python level introducing a class hierarchy with
inheritance. Again nothing really difficult, testing and suggestions
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev