generic xml merge possible?

Discussion in 'XML' started by ilikesluts@gmail.com, Feb 28, 2006.

  1. Guest

    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
     
    , Feb 28, 2006
    #1
    1. Advertising

  2. > 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
     
    Joe Kesselman, Feb 28, 2006
    #2
    1. Advertising

  3. Guest

    merges them
     
    , Feb 28, 2006
    #3
  4. 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
     
    Joe Kesselman, Feb 28, 2006
    #4
  5. Andy Dingley Guest

    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.
     
    Andy Dingley, Feb 28, 2006
    #5
  6. Guest

    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 <> wrote:
    > 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.
     
    , Feb 28, 2006
    #6
  7. 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



    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 <> wrote:
    >> 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.

    >
     
    =?ISO-8859-1?Q?R=E9mi_Peyronnet?=, Feb 28, 2006
    #7
  8. Guest

    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?
     
    , Feb 28, 2006
    #8
  9. 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
     
    Joseph Kesselman, Feb 28, 2006
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Murat Tasan
    Replies:
    1
    Views:
    8,120
    Chaitanya
    Feb 3, 2009
  2. Markus
    Replies:
    7
    Views:
    1,419
  3. Jacinle Young
    Replies:
    3
    Views:
    461
    Jacinle Young
    Jun 28, 2004
  4. Replies:
    2
    Views:
    473
  5. Bas
    Replies:
    3
    Views:
    256
    Steven D'Aprano
    May 1, 2007
Loading...

Share This Page