Re: [xml] xml diff and patch support -- new node type

[Daniel Veillard <veillard redhat com>]

On Mon, Jan 31, 2005 at 04:55:25PM -0800, Mark Vakoc wrote:
> Daniel,
>
> I'm midway through implementing what I hope to be a rather flexible diff (and
> eventually patch) implementation for libxml2.  Flexible in the sense that it
> should be able to output different output formats though I will likely only be
> implementing one (probably the microsoft XmlDiffPatch diffgram format).

  Cool, I sent a mail a couple of years ago asking for someone
to implement a diff :-)

> Couple of general things about it:
> * the diff API will only take URIs rather than xmlDocPtr's because it is
> destructive to the documents and also requires access to all fields to store
> hashes, relative positions, misc items (including _private) for the source and
> target document

  Well you make the code so you handle the restrictions, but what about 
an API doing an xmlCopyDoc ? And do you need to modify both documents ?

> * I'm adding a xmlHashMultiTable that is a hash multimap where the sort key
> need not be unique.  It is also implemented to allow front and back access to
> entries when duplicate entries exist (making easy FIFO or FILO access).  In
> addition the user is responsible for computing the hash key (it accepts an
> unsigned long to add/lookup functions)

  Not sure I understand :-) Let see the API !

> * I really need to add another node type to XML_ELEMENT_TYPE for a condensed
> node, that is a representation of subtrees and/or sequences (adjacent siblings)
> that are identical between the source and target diff documents.  It can follow
> the same rules as XML_ELEMENT_NODE for deallocation.

  Hum, that is annoying. It's gonna break lot of stuff. If such node are
never exposed afterward, I suggest to not add it to ElementType.

> Just a heads up and want to make sure adding a new value to the xmlElementType
> enum is ok before I commit to that.  Should have a patch ready in a week or
> two.

  I would rather make a #define for the new element type and avoiding 
it from escaping the scope of the xmldiff C module.

  thanks !

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/