generic xml merge possible?

I

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
 
J

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.
 
J

Joe Kesselman

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.
 
A

Andy Dingley

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.
 
?

=?ISO-8859-1?Q?R=E9mi_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



(e-mail address removed) a écrit :
 
I

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>
 
J

Joseph Kesselman

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,567
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top