Re: [xml] Potential wrong usage of xmlIsID() in tree.c
- From: Rob Richards <rrichards ctindustries net>
- To: cazic gmx net
- Cc: xml gnome org
- Subject: Re: [xml] Potential wrong usage of xmlIsID() in tree.c
- Date: Sat, 25 Feb 2006 08:09:06 -0500
cazic gmx net wrote:
No problem. Wasn't sure if you already had something in mind here or it
was just for potential future use.
The one question I have regards the function signatures. I'm assuming
that the ones with leading comments are the ones to be exposed
(everything marked static right now). For the options parameter. Are
options going to be used often? If not, it might make sense to make them
part of the xmlDOMWrapCtxt structure.
I marked it optional, since we do not yet use the context in those
functions. But this is just an initial design, and it might end up being
mandatory at the end.
Also, since the context is optional, it might make sense to pass it last
(the functions then are very close to the existing libxml2 functions.
I wanted the arg-list to be similiar to the other xmlDOMWrapXXX functions.
Again not a problem. Was just brainstorming and threw that out there.
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 :)
I would also eleminate the doc parameter in most cases. This should be
able to be determined from the node being passed in (at least for these
OK, for me.
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).
const xmlChar *name, const xmlChar *value,
Do we know how we will end up in the end? We'll lose flexibility for return
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.
Moving the context paramter is not a big deal as I see it is already
passed first in other of the xmlDOM... functions. Just thought it would
make the mapping to the existing similar functions easier if possible.
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?
] [Thread Prev