RE: [xml] Substitution of nested entity references

["Henke, Markus" <Markus_Henke ordat com>]

> -----Original Message-----
> From: Daniel Veillard [mailto:veillard redhat com]
> Sent: Tuesday, April 09, 2002 7:06 PM
> To: Henke, Markus
> Cc: 'xml gnome org'
> Subject: Re: [xml] Substitution of nested entity references
>
>   Okay, let's see ...
>
> > > <cut />
> > > - Is it possible that someone can get a xmlDocPtr to a non
> > >   well-formed (possibly due to cyclic entity references)
> > >   document? This could cause serious problems in this
> > >   routine... 8)
>
>   Not possible, well at  least for a document which is the 
> result of the
> parsing process.

Well, then i guess it's OK.

> > > - Is xmlGetDocEntity() the proper way to lookup the entity
> > >   declaration in that case? There is also xmlGetDtdEntity(),
> > >   i'm not shure about the difference. Both take a xmlDocPtr
> > >   as parameter (and i must confess that i haven't had the
> > >   time by now to examine the source for that...)
>
>   Use xmlGetDocEntity() it will look in both the internal subset and
> external subset for the entities definitions.

OK, i've used that (u can see the code in the original posting).
 
> > > - I've assumed that a xmlEntity have only child nodes with
> > >   type XML_ENTITY_REF_NODE or XML_TEXT_NODE. Is this correct,
> > >   and if not, which additional cases were to take into
> > >   consideration?
>
>   Well an entity content can be any "well balanced chunk", i.e.
> the result of the content [43] production:
>
>     http://www.w3.org/TR/REC-xml#NT-content

So we have XML_TEXT_NODE, XML_ENTITY_REF_NODE, XML_ELEMENT_NODE,
XML_CDATA_SECTION_NODE, XML_PI_NODE and XML_COMMENT_NODE.
The first two are already covered.
I guess from the last two we don't want to have any content
when resolving an entity reference?
For XML_ELEMENT_NODE and XML_CDATA_SECTION_NODE we could use
xmlNodeGetContent(), assumed that xmlResolveEntityRef() is
build in to resolve entity references that are contained by
a XML_ELEMENT_NODE?
 
> > > I would be glad to improve this routine if there is any
> > > chance that it could be used in libxml2 to resolve nested
> > > entity references, i guess at least xmlNodeGetContent and
> > > xmlGetProp() [xmlGetNsProp()] should do so, the reference
> > > says
> > > ... Entity references are substituted... e.g.
> > > ... This does the entity substitution...
>
>   Hum, the best would be to testcase xmlResolveEntityRef() 
> against the result of running the parser with entity substitution
> turned on. If the result were the same for the set of files in the
> test suite, that would be an indication that the code is good
> enough for inclusion directly in libxml2.

I'm not sure if i got you right.
Does libxml2 resolve nested entity references if entity
substitution is turned on (how?)?
If not, we'll get different results with any test that
includes nested references.
Or is it about testing backwards compatibility for the case
of non-nested entity references?

However, there are some general points i'm not sure
about:

- How to run the (existing?) tests in a Win32 environment
(which is my development platform)?

- To get a usefull result, xmlResolveEntityRef() has to be
included in the libxml2 source, hum, wherever an entity is
resolved :)
So, e.g. xmlGetProperty() and xmlNodeGetContent() are
candidates, but surely there are more. How to find them all?

- Or do you don't intend to include xmlResolveEntityRef()
in existing API routines (if it's coompleted & tested),
rather as an independent routine (some kind of "low-level"
entity resolving)?

- Maybe off-topic, but i still have no tool to generate
suitable diff-files in a Win23/VC++ environment.
Do you (or anyone else) have an idea?
(The last patches i've send where handmade, which is
quite awkward... 8)
Maybe i should ask Igor...

 
> Daniel

Thanx, Markus