Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > XML > generic xml merge possible?

Reply
Thread Tools

generic xml merge possible?

 
 
ilikesluts@gmail.com
Guest
Posts: n/a
 
      02-28-2006
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

 
Reply With Quote
 
 
 
 
Joe Kesselman
Guest
Posts: n/a
 
      02-28-2006
> 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
 
Reply With Quote
 
 
 
 
ilikesluts@gmail.com
Guest
Posts: n/a
 
      02-28-2006
merges them

 
Reply With Quote
 
Joe Kesselman
Guest
Posts: n/a
 
      02-28-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
Andy Dingley
Guest
Posts: n/a
 
      02-28-2006

(E-Mail Removed) 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.

 
Reply With Quote
 
fischer@sofika.de
Guest
Posts: n/a
 
      02-28-2006
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 <(E-Mail Removed)> wrote:
> (E-Mail Removed) 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.


 
Reply With Quote
 
=?ISO-8859-1?Q?R=E9mi_Peyronnet?=
Guest
Posts: n/a
 
      02-28-2006
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 Removed) 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 <(E-Mail Removed)> wrote:
>> (E-Mail Removed) 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.

>

 
Reply With Quote
 
ilikesluts@gmail.com
Guest
Posts: n/a
 
      02-28-2006
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?


 
Reply With Quote
 
Joseph Kesselman
Guest
Posts: n/a
 
      02-28-2006
(E-Mail Removed) 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
not just generic type programming,but also parallism generic syntaxprogramming?? minlearn C++ 2 03-13-2009 05:17 PM
generic interfaces with generic methods Murat Tasan Java 1 02-03-2009 12:17 PM
Generic class in a non generic class nramnath@gmail.com Java 2 07-04-2006 07:24 AM
XML transfrom: merge 2 or more different XML file into one Jacinle Young XML 3 06-28-2004 01:20 AM
Compare & Merge XML documents Michael Ransburg Java 0 02-16-2004 02:23 PM



Advertisments