XML doc generation

[Harry George]

Our standard approach is:
  App1 --> app1's datafile --> python OO model of app1 data --> 
  python neutral representation --> python OO model of app2 data
  --> app2's datafile

Sometimes, app1 or app2 have XML as their datafile formats (not the
*same* XML DTD of course).  As Paul says, the hard transformations are
done python-to-python.  You can go point-to-point or use a neutral
representation hub-and-spoke mechanism.

In those cases where XML is the desired output, I've tried both ways:

  a) Each object has a "to_xml" methods, and you recursively traverse
  the tree generating xml by hand
  b) Each object has a "to_dom" method, and you recursively traverse
  the tree generating the dom.  Then run "dom.PrettyPrinter" or
  whatever to get the actualy XML.

The problem with "a" is that you have to write more code (not much
more, but some), and need to do your own tabbed-writer to get indents.
The problem with "b" is that you must accept the xml writer's idea of
the proper output format.  Thus, attributes may be in hash order or
alpha sort order where you really wanted some other order.  So it's a
tradeoff.

Paul Prescod <paulp at ActiveState.com> writes:

> Jonathan Pennington wrote:
> > 
> >...
> > 
> > Well, I trust your judgement there. As a reformed perl and PHP
> > programmer, I can write text into a file in my sleep :-) However, one
> > last question. If I wanted to download this coordinate info, then
> > manipulate it as a DOM, would that still be easier. In other words, as
> > stated above, I would download data from the receiver directly into an
> > XML file, then parse the XML file into memory, display/manipulate it,
> > then rewrite it to the file when saved. 
> 
> Even in the case where the data came from XML, it may or may not be
> easiest to manipulate it *as* XML. If you are doing lots of complicated
> manipulations, it might be easier to do it in some other data structure. 
> 
> Imagine if I had a matrix encoded as an XML "table". Doing a transform
> to rotate the table would be a lot more work than doing the equivalent
> with simple Python lists or with NumPy arrays.
> 
> On the other hand, if you were just running around the tree adding a few
> attributes or something then it would be easier to keep it as a DOM for
> the whole program.
> 
> > Do I understand correctly. It
> > does sound easy enough, I just want to make sure that I'm not missing
> > something or making things difficult with all that file I/O. Thanks.
> 
> A lot of people are nervous that writing out tags is an inappropriate
> way to generate XML. That's natural. But it tends to be simpler than the
> alternatives and about as robust.
> 
>  Paul Prescod
> 

-- 
Harry George
hgg9140 at seanet.com