Re: [xml] Potential wrong usage of xmlIsID() in tree.c

[Rob Richards <rrichards ctindustries net>]

Kasimier Buchcik wrote:
> > It really depends upon how much a function is going to be implementing
> > the DOM function and what the wrapper is to be responsible for (see next 
> > comments for more). This could also be another potential use of the 
> > xmlDOMWrapCtxt structure. The errors in DOM are pretty standard and if a 
> > wrapper wanted to know specific errors it could get it from the 
> > structure. Just an idea as it's just my personal preference for 
> > simplified function signatures when possible - easier to remember :)
> >     
>
> So a ctxt->err field, right? OK, with me.
> Would you return the removed attr in a context field as well? E.g.
> ctxt->resultNode of type xmlNodePtr.
>
> I would really like to keep an int as the result, since there might
> be scenarios, where we would get an internal error and still want
> to return the removed or to-be-removed attr for inspection.
>   
I don't think the returned node should be put into the context. Unlike a 
specific error codes or options (where the caller might not care about 
these), returning nodes in the context would then require the context to 
always be passed. This argument though is only valid if the context is 
still going to be optional.

Do you have an example case for this scenario? If you are meaning to 
return a different node than the expected returned node via the same 
parameter, I think that would be a bit confusing. Not saying that 
returning an int as the result is bad, just that if done this way, 
returning a node for possible inspection rather than the expected return 
value should be handled differently.

Rob