generic xml merge possible?

[ilikesluts]

Hi Group,

I'm new to XML, here is my question:

Would it be possible to write an algorithm that takes in two XML
documents with the only condition being that they have the same root
element? If it is possible what would be the best technology to
implement the solution (XMLDom, XSLT...)? How hard would the solution
be?

Thanks

[Joe Kesselman]

> Would it be possible to write an algorithm that takes in two XML

documents with the only condition being that they have the same root
element?

And does what with them? If you want an answer, you need to ask a
complete question.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[ilikesluts]

merges them

[Joe Kesselman]

il********@gmail.com wrote:

merges them

The simple answer it that this can be done using any generic XML
processing tool. I'd do it in XSLT, myself. The complex answer is that
this becomes an arbitrarily complex task depending the details of
exactly what you mean by merge.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Andy Dingley]

il********@gmail.com wrote:

Would it be possible to write an algorithm that takes in two XML
documents

Yes.

The next question is what "merge" means. Simple concatenation?
Immediate root-children sorted by some definable key? What happens if
there's a "duplicate" element, and how might you define duplicate?

For grinding data files by hand, I generally use XSLT and XPath. This
works fine for one-off hacks with smaller documents. If I started to
care about algorithms and performance I might look at programs that ran
over the DOM, or even something using SAX (if they were huge documents
with simple merges)

Algorithms from the '60s (read Knuth !) start to look interesting
again, when you're dealing with merge-sorts on datasets to big to hold
in memory (i.e. DOM) simultaneously.

[fischer]

You can merge xml-files with the toolbox <xml>cmp
(http://www.xmlcmp.com).
<xml>cmp is desigend for merging, comparing, sorting and regrouping
large files by low memory consumption.


Andy Dingley <di*****@codesmiths.com> wrote:

il********@gmail.com wrote:

Would it be possible to write an algorithm that takes in two XML
documents

Yes.

The next question is what "merge" means. Simple concatenation?
Immediate root-children sorted by some definable key? What happens if
there's a "duplicate" element, and how might you define duplicate?

For grinding data files by hand, I generally use XSLT and XPath. This
works fine for one-off hacks with smaller documents. If I started to
care about algorithms and performance I might look at programs that ran
over the DOM, or even something using SAX (if they were huge documents
with simple merges)

Algorithms from the '60s (read Knuth !) start to look interesting
again, when you're dealing with merge-sorts on datasets to big to hold
in memory (i.e. DOM) simultaneously.

[Rémi Peyronnet]

Hi,

For a free solution : http://freshmeat.net/projects/libxmldiff/

The outputted diff is a simple merge with "diff:status attributes" ; so
if you are only interested in merging files, you only have to delete the
diff:status attribute by "delete //@diff:status"

Hth,

--
Rémi Peyronnet

fi*****@sofika.de a écrit :

You can merge xml-files with the toolbox <xml>cmp
(http://www.xmlcmp.com).
<xml>cmp is desigend for merging, comparing, sorting and regrouping
large files by low memory consumption.


Andy Dingley <di*****@codesmiths.com> wrote:

il********@gmail.com wrote:

Would it be possible to write an algorithm that takes in two XML
documents

Yes.

The next question is what "merge" means. Simple concatenation?
Immediate root-children sorted by some definable key? What happens if
there's a "duplicate" element, and how might you define duplicate?

For grinding data files by hand, I generally use XSLT and XPath. This
works fine for one-off hacks with smaller documents. If I started to
care about algorithms and performance I might look at programs that ran
over the DOM, or even something using SAX (if they were huge documents
with simple merges)

Algorithms from the '60s (read Knuth !) start to look interesting
again, when you're dealing with merge-sorts on datasets to big to hold
in memory (i.e. DOM) simultaneously.

[ilikesluts]

Duplicate elements would be one problem. I think that another one
would be if you had merged in an element that had the same ancestors as
another element. Would you create a new branch or would you make it a
sibling? I think that it could change the meaning of the data for some
applications.

<a>
<b>
<c>Hi</c>
</b>
<b>
<d>Hello</d>
</b>
</a>

versus:

<a>
<b>
<c>Hi</c>
<d>Hello</d>
</b>
</a>

The next question is what "merge" means. Simple concatenation?
Immediate root-children sorted by some definable key? What happens if
there's a "duplicate" element, and how might you define duplicate?

[Joseph Kesselman]

il********@gmail.com wrote:

Duplicate elements would be one problem. I think that another one
would be if you had merged in an element that had the same ancestors as
another element. Would you create a new branch or would you make it a
sibling? I think that it could change the meaning of the data for some
applications.

Which is why the concept of "merge" has to be defined more precisely --
either as a generic one-size-fits-some-but-not-all operation, or on an
application-by-application basis.
--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden