sean.upton at uniontrib
Oct 22, 2001, 2:52 PM
Post #2 of 8
I think this is an interesting approach that would also work: merge your
RE: storing XML can be good... was Re: ANNOUNCE: PT_XP ath
[In reply to]
flat changes into righ XML as needed, preserving the XML structure and
previously value added data...
The advantage to ParsedXML, of course, is that for read purposes, it is
already parsed into a DOM, and shouldn't require parsing, if I understand
correctly, except for the occasional re-read after modification.
I never understood the use of BLOBs in RDB when using coupled with an object
database. Perhaps one solution is to have a container-type object in the
ZODB that contains both a dumb-slow-DOM and a bunch of
smart-fielded-objects, and a merge with the dumb-slow-DOM could be done from
the custom objects as needed... In my case, though, I would want people
other than myself to be able to extend the API as needed, so I still like
the simplicity of being able to support new behaviors in TTW python scripts
that could be written by a slightly techical person with enough experience
playing with DOM to get what they want.
From: Wade Leftwich [mailto:wade [at] lightlink]
Sent: Monday, October 22, 2001 12:11 PM
To: Martijn Pieters; sean.upton [at] uniontrib
Cc: zope-xml [at] zope
Subject: Re: storing XML can be good... was Re: [Zope-xml] ANNOUNCE:
I am in a situation similar to Sean's, sending and receiving a bunch of
newsfeeds in NITF format. (Hi Sean, i think we met up on the NITF list a
Because I'm adding on to (and hoping to replace) an ASP system, I've got all
my data in MSSQL. My tables have the usual columns that Sean alluded to:
headline, byline, date, etc. I also keep the original NITF-
XML in a bigtext field. I run a cron job to rewrite the XML if any of the
other fields gets edited.
Right now I don't think I would want to give up the RDB storage, even if I
didn't need it for historical reasons. While each article is a tree, the
organization at higher levels is definitely tabular. And many people
I would love to be able to access the tree structure of each article within
Zope, without first parsing XML to a DOM. Having done a fair amount of work
with DOM, I hear what Martijn is saying about it being fat and
slow. What about an object representation, like Martijn suggested, that
could live in a BLOB in an RDB?
10/22/2001 2:26:41 PM, Martijn Pieters <mj [at] zope> wrote:
>On Mon, Oct 22, 2001 at 10:40:09AM -0700, sean.upton [at] uniontrib wrote:
>> I hear more and more often that XML should not be stored, and just be an
>> interchange format. And in most cases, that is likely to be correct,
>> I think there are some very convincing reasons to, indeed, store XML on
>> server for particular use cases. The best possible illustration that I
>> think of is a use case that I have; sorry that this 'manifesto for
>> XML' is so lengthy, but I think this position needs definitive
>> - and I think that for this use case below, I'm right... ;)
>> Eventually, for our internal use, my company will likely be creating a
>> product that will support the use and storage of NITF (News Industry Text
>> Format) and NewsML - both standards for news content defined by the IPTC
>> (International Press Telecommunications Council) and/or the Newspaper
>> Association of America (NAA). These DTDs were designed to address
>> deficiencies in current information flow in the newspaper industry; NITF,
>> particular, began in the pre-XML days, as an SGML DTD with the specific
>> of allowing news producers/vendors to scrap the 150 or so different
>> proprietary text interchange and storage formats used by the industry.
>> idea was that in translation (filtering) between lots of formats,
>> information is almost always lost, and always costly.
>To me, this is still no reason to justify an XML storage. Note that Zope
>doesn't force you to use a fixed number of fields; the object tree and
>python provide you with much more flexibility. I am convinced that it is
>posible to build a Zope app with the same fidelity as the NITF, with
>lossless conversion between the internal storage format and NITF.
>Using Zope objects instead of XML would buy you speed and scalability. DOMs
>are memory hogs, and CPU intensive to build and manipulate. Only use a DOM
>when a custom API isn't feasable. Don't carry around all that extra weight
>if you can avoid it!
>| Software Engineer mailto:mj [at] zope
>| Zope Corporation http://www.zope.com/
>| Creators of Zope http://www.zope.org/
>Zope-xml mailing list
>Zope-xml [at] zope