Converting between two different XML forms

  • Follow


Ok, I have been tasked with converting one XML doc to another. The
structures of which are radically different. I mean, to fill in the
fields of XML B I need to mannually pick fields from XML A. XML B is
attribute based, XML A is tag based -- it's ugly folks.

So, I have investigated xslt -- which showed some promise -- but given
my poor knowledge of the subject it seemed to be that I could get
bogged down in formatting details and learning the syntax of xslt
(which I am not completely against if it turns out the be for the
best).

Then I thought, Ok, I can serialize both into objects and do the manual
translation that way (then atleast I could work in a realm I was
familiar with).

Does someone have an idea that could save me time and hassle for an
otherwise mindless task?

Christian
http://christian.bongiorno.org/resume.pdf

0
Reply cbongior (40) 8/4/2005 5:00:22 PM

In article <1123174822.473311.27570@g49g2000cwa.googlegroups.com>,
 cbongior@stny.rr.com wrote:

> Ok, I have been tasked with converting one XML doc to another. The
> structures of which are radically different. I mean, to fill in the
> fields of XML B I need to mannually pick fields from XML A. XML B is
> attribute based, XML A is tag based -- it's ugly folks.
> 
> So, I have investigated xslt -- which showed some promise -- but given
> my poor knowledge of the subject it seemed to be that I could get
> bogged down in formatting details and learning the syntax of xslt
> (which I am not completely against if it turns out the be for the
> best).
> 
> Then I thought, Ok, I can serialize both into objects and do the manual
> translation that way (then atleast I could work in a realm I was
> familiar with).
> 
> Does someone have an idea that could save me time and hassle for an
> otherwise mindless task?
> 
> Christian
> http://christian.bongiorno.org/resume.pdf

I'm not greatly experienced at xslt, but I do suspect it'll be your best 
bet overall.  Is this a one-time manual task or an ongoing application 
requirement?  That would make a difference for me in the direction I 
chose to pursue.

My work with XML has been pure DOM -- parse the document into a DOM 
Document (serialization is for output, not input).  If you know enough 
of the structure of both to set up logic for finding pieces of the old 
document, you can readily create the elements and/or attributes needed 
in the new one.  And XPath could well help you to navigate the old one 
in order to get what you need from it.

= Steve =
-- 
Steve W. Jackson
Montgomery, Alabama
0
Reply stevewjackson2 (645) 8/4/2005 6:36:39 PM


cbongior@stny.rr.com wrote:
> Ok, I have been tasked with converting one XML doc to another. The
> structures of which are radically different. I mean, to fill in the
> fields of XML B I need to mannually pick fields from XML A. XML B is
> attribute based, XML A is tag based -- it's ugly folks.
> 
> So, I have investigated xslt -- which showed some promise -- but given
> my poor knowledge of the subject it seemed to be that I could get
> bogged down in formatting details and learning the syntax of xslt
> (which I am not completely against if it turns out the be for the
> best).

XSLT, IMO, is really only useful if you have a lot of fixed boiler plate 
you want to insert XML data into. The syntax is hopeless. Luckily you 
are going away from attributes, because creating attributes with XSLT is 
even more verbose than usual.

XQuery looks quite nice, but I haven't used it. And it seems to have 
arrived too late for all the hype.

I guess you know where you are at in relation to JAXB and JDOM.

Tom Hawtin
-- 
Unemployed English Java programmer
http://jroller.com/page/tackline/
0
Reply usenet120 (1481) 8/4/2005 6:53:36 PM

<cbongior@stny.rr.com> wrote in message
news:1123174822.473311.27570@g49g2000cwa.googlegroups.com...
> Ok, I have been tasked with converting one XML doc to another. The
> structures of which are radically different. I mean, to fill in the
> fields of XML B I need to mannually pick fields from XML A. XML B is
> attribute based, XML A is tag based -- it's ugly folks.
>
> So, I have investigated xslt -- which showed some promise -- but given
> my poor knowledge of the subject it seemed to be that I could get
> bogged down in formatting details and learning the syntax of xslt
> (which I am not completely against if it turns out the be for the
> best).
>
> Then I thought, Ok, I can serialize both into objects and do the manual
> translation that way (then atleast I could work in a realm I was
> familiar with).
>
> Does someone have an idea that could save me time and hassle for an
> otherwise mindless task?
>
> Christian
> http://christian.bongiorno.org/resume.pdf
>

Depending on your timeconstraints, it may be well worth looking into XSLt.
You may want to use it again in the future.

XSLT has quite a steep learning curve. Not so much the syntax (there are
editors out there help you a lot with that, XML Spy, Xselerator, etc), but
the mind-set of writing XSL stylesheets. It is a declarative meta-language
(no updating of variables, for example) and instead of thinking that one
template calls another one, you have to think about selecting and matching
XML-nodes.

But as soon as you learn XSLT, you can write XSL stylesheets really quickly
for such tasks as you are working on now.
-- Anton.


0
Reply Anton 8/5/2005 8:16:53 PM

3 Replies
19 Views

(page loaded in 0.129 seconds)


Reply: