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

> Would it be possible to write an algorithm that takes in two XML[color=blue]
> documents with the only condition being that they have the same root
> element?[/color]

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

merges them

ilikesluts@gmail.com wrote:[color=blue]
> merges them[/color]

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

ilikesluts@gmail.com wrote:
[color=blue]
> Would it be possible to write an algorithm that takes in two XML
> documents[/color]

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.

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 <dingbat@codesmiths.com> wrote:[color=blue]
> ilikesluts@gmail.com wrote:
>[color=green]
> > Would it be possible to write an algorithm that takes in two XML
> > documents[/color]
>
> 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.[/color]

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



fischer@sofika.de a écrit :[color=blue]
> 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 <dingbat@codesmiths.com> wrote:[color=green]
>> ilikesluts@gmail.com wrote:
>>[color=darkred]
>>> Would it be possible to write an algorithm that takes in two XML
>>> documents[/color]
>> 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.[/color]
>[/color]

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>

[color=blue]
> 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?[/color]

ilikesluts@gmail.com wrote:[color=blue]
> 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.[/color]

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