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

[Kasimier Buchcik <K Buchcik 4commerce de>]

Hi,

On Sat, 2006-02-25 at 08:09 -0500, Rob Richards wrote:
> cazic gmx net wrote:

[...]

> > > functions). Lastly, if the function is only returning a 0 or -1, would 
> > > it make more sense to just return the actual attribute (again similar to 
> > > the libxml2 function).
> > > i.e.:
> > > xmlAttrPtr
> > > xmlDOMWrapSetAttr(xmlNodePtr owner,
> > >           xmlNsPtr ns,
> > >           const xmlChar *name, const xmlChar *value,
> > >           xmlDOMWrapCtxtPtr ctxt)
> > >     
> >
> > Do we know how we will end up in the end? We'll lose flexibility for return
> > values.
> >   
> 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.
   
[...]

> > It recurred to me that we need also a check for fixed attributes being tried
> > to be modified/replaced, in which case it would be nice to return the
> > corresponding DOM error NO_MODIFICATION_ALLOWED_ERR.
> > Although the INUSE_ATTRIBUTE_ERR can be handled on the wrapper's side, do
> > you think we should add that as well?
> >   
> Undecided at the moment. What I'm afraid of is that a DOM implementation 
> in the library will continually grow to support all the DOM nuances 
> causing the lib to get even larger. If I switch over to using the DOM 
> functions and a configure switch is added to allow for the DOM functions 
> to be disabled when building the library, I am just worried that some 
> distros may disable the functionality by default. If the new 
> functionality is kept at a minimum and the wrapper side handles some of 
> the burden there is probably a much lower possibility of the 
> functionality being disabled.


Regards,

Kasimier